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Conventions  and  Terminology 

Conventions 

The  notation,  formatting,  and  conventions  used  in  this  System  Protection  Profile  are  consistent  with 
those  used  in  Version  2. 1 of  the  Common  Criteria  [CC].  Selected  presentation  choices  are 
discussed  here  to  aid  the  System  Protection  Profile  reader.  The  CC  allows  several  operations  to  be 
performed  on  functional  requirements:  The  allowable  operations  defined  in  paragraph  2.1.4  of  Part  2 of 
the  CC  [CC2]  are  refinement,  selection,  assignment  and  iteration. 

The  assignment  operation  is  used  to  assign  a specific  value  to  an  unspecified  parameter,  such 
as  the  length  of  a password.  An  assignment  operation  is  indicated  by  showing  the  value  in 
square  brackets,  i.e.  [assignment  va ! ue( s)  . 

• The  refinement  operation  is  used  to  add  detail  to  a requirement,  and  thus  further  restricts  a 
requirement.  Refinement  of  security  requirements  is  denoted  by  bold  text. 

• The  selection  operation  is  picking  one  or  more  items  from  a list  in  order  to  narrow  the  scope  of 
a component  element.  Selections  are  denoted  by  underlined  italicized  text. 

• Iterated  functional  and  assurance  requirements  are  given  unique  identifiers  by  appending  to  the 
base  requirement  identifier  from  the  CC  an  iteration  number  inside  parenthesis,  for  example, 
FMTMTD.1.1  (1)  and  FMTMTD.1.1  (2)  refer  to  separate  instances  of  the  FMT  MTD.  1 
security  functional  requirement  component. 

All  operations  described  above  are  used  in  this  System  Protection  Profile.  Italicized  text  is  used  for  both 
official  document  titles  and  text  meant  to  be  emphasized  more  than  plain  text. 

Terminology 

The  terminology  used  in  the  System  Protection  Profile  is  that  defined  in  the  Common  Criteria 
[CC1,  CC2],  A glossary  has  also  been  provided  in  Appendix  A - Acronyms. 
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Document  Organization 


Section  1 provides  the  introductory  material  for  the  System  Protection  Profile. 

Section  2 provides  general  purpose  and  STOE  description. 

Section  3 provides  a discussion  of  the  expected  environment  for  the  STOE.  This  section  also 
defines  the  set  of  threats  that  are  to  be  addressed  by  either  the  technical,  operational  or  management 
controls  implemented  by  the  STOE  or  through  the  environmental  controls. 

Section  4 identifies  the  risks  to  the  STOE  that  have  been  derived  from  the  statement  of  the  security 
environment  defined  in  section  3. 

Section  5 defines  the  security  objectives  for  both  the  STOE  and  the  STOE  environment. 

Section  6 contains  the  functional  and  assurance  requirements  derived  from  the  Common  Criteria,  Part  2 
and  3 [CC2,  CC3],  respectively  that  must  be  satisfied  by  the  STOE. 

Section  7 contains  guidance  information  for  SST  authors  who  would  like  to  claim  conformance  to  the 
SPP. 

Section  8 provides  a rationale  to  explicitly  demonstrate  that  the  identified  risks  to  the  STOE  have  been 
derived  from  the  aspects  identified  in  the  security  environment.  It  also  demonstrates  how  the  security 
objectives  have  been  derived  from  each  of  the  identified  risks.  The  section  then  explains  how  the  set  of 
requirements  are  complete  relative  to  the  objectives,  and  that  each  security  objective  is  addressed  by  one 
or  more  component  requirements.  Arguments  are  provided  for  the  coverage  of  each  objective.  Section 
8 also  provides  a set  of  arguments  that  address  dependency  analysis,  strength  of  function  issues, 
and  the  internal  consistency  and  mutual  supportiveness  of  the  System  Protection  Profile  requirements. 

Appendix  A documents  an  acronym  list  to  define  frequently  used  acronyms  applicable  to  the  STOE. 
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1 Introduction 

This  introductory  section  presents  System  Protection  Profile  (SPP)  identification  information  and  an 
overview  of  the  SPP. 

LI  SPP  Identification 

This  section  provides  information  needed  to  identify  and  control  this  SPP.  This  SPP  targets  an 
extended  Evaluation  Assurance  Level  (EAL)  3 level  of  assurance  for  the  STOE. 


SPP  Title: 

SPP  Version: 

CC  Version: 

SPP  Evaluation: 

Author(s): 

Keywords: 


System  Protection  Profile  - Industrial  Control  Systems 
1.0 

Common  Criteria  for  Information  Technology  Security  Evaluation, 
Version  2.1  Final 

National  Information  Assurance  Partnership 
National  Institute  of  Standards  & Technology 
Industrial  Control  Systems 


1.2  SPP  Overview 

SPP  Background 

This  SPP  has  been  developed  as  part  of  the  Process  Control  Security  Requirements  Forum 
(PCSRF)  sponsored  by  the  National  Institute  of  Standards  and  Technology  (NIST).  This  SPP  is 
intended  to  provide  an  ISO  15408  based  starting  point  in  formally  stating  security  requirements 
associated  with  industrial  control  systems  (ICS).  This  SPP  includes  security  functional 
requirements  (SFRs)  and  security  assurance  requirements  (SARs)  that  extend  ISO  15408  to  cover 
issues  associated  with  systems.  These  extensions  are  based  on  current  ISO  subcommittee  work  to 
extend  ISO  15408  to  cover  the  accreditation  of  systems  and  the  evaluation  of  system  protection 
profiles  and  system  security  targets.  These  extensions  broaden  consideration  of  security  controls 
to  include  non-technical  controls  based  on  procedural  and  management  functions. 

Industrial  Process  Security 

Continued  existence  of  modem  society  is  dependent  on  its  industry  and  infrastructure  and  its 
ability  to  control  electrical,  chemical  and  mechanical  transformations  of  materials  and  energy  to 
produce  desired  results. 

Generally,  an  ICS  is  a computer-based  system(s)  used  to  control  industrial  processes  and  physical 
functions.  Industrial  control  systems  automate  these  control  functions  allowing  for  industrial 
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processes  that  are  faster,  larger  and  more  complex  than  non-automated  means.  The  ICS  and 
associated  systems  assure  the  safe  and  environmentally  acceptable  operation  of  a specific 
industrial  process. 

The  ultimate  goal  of  an  ICS  is  to  assure  the  specified  operational,  safety  and  environmental 
compatibility  of  a specified  industrial  process  such  as  a power  plant  and  its  distribution  network. 
The  “specified  operation"  may  be  “continued  operation"  or  “demand  operation."  For  example,  a 
power  plant  operation  generally  is  supposed  to  be  continuous  while  an  emergency  power 
generator  typically  is  supposed  to  operate  on  demand  only.  Safety  and  environmental 
compatibility  means  that  neither  personnel  safety,  nor  the  quality  of  the  environment  (natural  or 
otherwise)  are  endangered. 

Therefore,  the  overall  security  concern  for  an  ICS  typically  originates  from  malicious  threat 
agents  attempting  to  disrupt  an  industrial  process  such  as  to  interfere  with  it  specified  operation 
(e.g.  to  create  a power  outage)  or  to  negatively  impact  on  the  environment  and/or  personnel 
safety  (e.g.  exploding  a fuel  tank  or  destabilizing  chemical  process  to  free  noxious  gases). 

It  is  worth  noting  that  attempting  to  capture  the  requirements  of  all  ICS  implementations  in  a 
single  document  is  not  feasible  due  to  the  differences  between  the  processes  and  the  networks 
deployed  across  various  industries.  However,  there  exists  a subset  of  those  security  requirements 
that  are  applicable  to  all  ICS  implementations.  This  subset  is  the  focus  of  this  SPP. 

The  SPP  has  been  written  in  such  a way  that  it  may  be  used  as  the  basis  for  preparing  a System 
Security  Target  for  a specific  ICS  or  as  the  basis  for  a more  detailed  SPP  for  a sub-class  of  ICS 
such  as  a Supervisory  Control  and  Data  Acquisition  System  (SCADA).  For  more  discussion  of 
the  role  of  this  SPP  refer  to  section  7.1  of  the  application  notes. 

ICS  Background 

There  are  several  varieties  of  ICS,  but  all  consist  of  the.  same  basic  elements.  As  shown  in  Figure 
1 those  components  are:  the  controller,  sensors,  actuators  (or  final  control  elements),  and  in  some 
cases  a human  machine  interface  (HMI)  and  a remote  diagnostics  and  maintenance  capability. 
These  components  may  be  in  close  physical  proximity  or  they  may  be  distributed  with  great 
distances  (many  miles)  between  some  of  the  elements)  depending  on  the  specific  application.  In 
addition  to  these  technical  elements  ICS  include  a human  element  including  operators, 
maintainers  and  engineers.  They  also  have  operating  procedures  and  other  non-technical 
elements. 

A simplified  view  of  the  operation  of  an  ICS  and  the  function  of  the  elements  is  as  follows.  The 
controller  implement  control  algorithms  based  on  a mathematical  model  of  the  process  to  be 
controlled  and  the  control  objectives.  The  sensors  sense  the  state  of  the  process  through 
measurement  of  process  parameters  such  as  temperature,  pressure,  voltage,  pH,  position,  size,  etc. 
The  state  of  the  process  may  change  due  to  external  "disturbances",  changes  in  the  process  inputs 
such  as  feed  material,  or  in  response  to  action  initiated  by  the  controller.  The  controller  processes 
the  sensor  information  and,  based  on  the  control  algorithm  and  desired  state  of  the  process,  sends 
commands  to  the  final  control  elements  which  in  turn  interact  with  the  controlled  process  to 
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affect  changes  in  its  state.  The  final  control  elements  take  many  different  forms  including  valves, 
switches,  relays,  motors,  and  so  forth  depending  on  the  nature  of  the  process  under  control.  The 
HMI  provides  a means  for  human  operators  to  monitor  the  state  of  the  process  and  the  ICS,  to 
interact  with  the  controller  to  change  the  control  objective  and  may  also  include  manual  control 
options  (for  the  case  of  emergency).  Similarly  there  may  be  a remote  diagnostics  and 
maintenance  interface  to  be  used  in  gathering  data  used  for  diagnostics,  maintenance,  emergency 
procedures  or  other  similar  activities. 

Need  for  an  ICS  SPP 

Recently,  several  factors  have  raised  concern  about  the  security  of  industrial  control  systems. 

First,  there  has  been  a general  trend  to  replace  specialized  control  devices,  particularly  controllers 
and  communications  elements,  with  general  purpose  computer  equipment  and  associated  data 
communications  technology.  Second,  many  companies  have  chosen  to  interconnect  certain  parts 
of  their  process  control  networks  with  their  corporate  intranet  once  they  have  introduced  general- 
purpose  equipment  into  the  process  control  system. 

These  two  factors  introduce  all  of  the  potential  vulnerabilities  found  in  the  network  computing  in 
general,  particularly  if  there  is  a path  through  the  corporate  intranet  to  the  Internet  at  large.  Third, 
for  ICS  that  are  broadly  distributed  a variety  of  communications  media  are  used  including  the 
public  switched  telephone  system,  wireless  communications  and  the  Internet.  There  are  potential 
security  vulnerabilities  associated  with  each  of  these  communications  paths.  Finally,  ICS  are  key 
components  of  much  of  our  national  critical  infrastructure  including  the  electric  power,  water  and 
water  treatment,  oil  and  gas  production  and  distribution  as  well  as  industrial  and  military 
manufacturing. 

To  address  these  vulnerabilities  organizations  are  primarily  installing  security  retrofits  or 
upgrades  to  existing  their  existing  ICS.  This  SPP  is  intended  to  provide  a basis  for  these 
activities  as  well  as  the  design  of  new  systems.  In  either  case,  the  security  functionality  should  be 
implemented  based  on  a risk  analysis  that  determines  security  requirements  based  on  an 
assessment  of  threats,  vulnerabilities  and  impacts. 

System  Protection  Profile  - Industrial  Control  Systems 

The  System  Protection  Profile  for  Industrial  Control  Systems  (SPP-ICS)  specifies  the  integrated 
set  of  security  requirements  for  industrial  control  systems.  The  integrated  set  of  requirements 
includes  requirements  for  operating  policies  and  procedures,  requirements  for  information 
technology  based  system  components,  requirements  for  interfaces  and  interoperability  between 
system  components,  and  requirements  for  the  physical  environment  and  protection  of  the  system. 

Because  the  SPP-ICS  represents  an  integrated  view  of  the  requirements,  special  consideration  is 
given  to  decomposition  of  security  functionality  and  assignment  of  specific  security  functions  to 
sub-systems  or  components  of  the  overall  integrated  system.  Likewise,  the  decomposition  or 
composability  of  the  security  functionality  is  also  considered.  The  goal  of  this  aspect  of  analysis 
and  design  is  to  define  security  requirements  for  subsystems  or  system  components  at  the  lowest 
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possible  level  while  at  the  same  time  retaining  the  required  level  of  assurance  and  security 
functionality  for  the  integrated  system  as  a whole. 


As  shown  in  Figure  1 an  industrial  control  system  consists  of  classes  of  components  for  the  direct 
control  of  a process  (the  controlled  s),  actuators  and  sensors)  a human  machine  interface  and 
capabilities  for  remote  diagnostics  and  maintenance.  Although  not  represented  in  the  diagram, 
there  are  also  human  elements  such  as  operators  and  non-technical  elements  such  as  operating 
procedures. 


Disturbances 


Figure  1:  Generic  industrial  control  system 


This  system  protection  profile  is  written  for  a generic  industrial  control  system  as  a high-level 
statement  of  requirements.  It  provides  a starting  point  for  more  specific  and  detailed  statements 
of  requirements  for  industrial  control  systems  focused  on  a specific  industry,  company,  or 
component. 
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2 STOE  Description 

This  section  provides  context  for  the  STOE  evaluation  by  identifying  the  system  and  describing  the 
evaluated  configuration. 

2.1  Overview  of  the  System  Target  of  Evaluation  (STOE) 

This  section  describes  the  security  subsystem  of  the  industrial  control  system.  The  security 
subsystem  includes  both  the  information  technology  based  components  and  the  non-information 
technology  based  elements  implemented  via  policies  and  operating  procedures.  Particular  attention 
is  given  to  the  interaction  and  dependencies  between  the  security  subsystem  and  the  overall 
industrial  control  system. 

The  STOE  focuses  on  protecting  data  confidentiality,  data  integrity  and  system  availability  without 
interfering  with  safety  system  functions.  Data  integrity  centers  on  protecting  data  flows  to  and  from 
the  controller  and  the  other  ICS  components  or  subsystems.  The  STOE  is  also  intended  to  protect 
system  availability  to  assure  continuity  of  operations. 

2.2  Scope  of  the  STOE 

The  STOE  consists  of  the  security  services  and  procedures,  both  automated  and  manual,  which  are 
designed  to  meet  the  security  objectives  defined  to  counter  threats  to  the  ICS. 

The  scope  of  the  STOE  is  depicted  graphically  in  Figure  2.  Boxes  with  bold  red  borders  depict  the 
primary  system  security  functions.  These  functions  are:  user  authentication  services  (including 
user  access  control),  physical  access  control,  boundary  protection,  and  data  / device  authentication. 
User  authentication  services  control  access  to  process  control  related  computer  systems  including 
the  human  machine  interface  (HMI)  and  remote  diagnostics  and  maintenance.  In  addition,  user 
authentication  is  used  by  the  physical  access  control  system  to  authenticate  personnel  for  physical 
access.  Data  / device  authentication  is  shown  as  a separate  function  to  emphasize  the  need  for  data 
and  command  signal  authentication.  Note  that  the  corporate  intranet  is  in  the  external  environment 
of  the  STOE. 

The  blue  lines  from  actuator  to  controlled  process  and  from  controlled  process  to  sensor  indicate 
that  these  are  physical  connections  representing  the  direct  interactions  that  take  place.  The  rest  of 
the  diagram  depicts  logical  connections.  Security  controls  based  on  management  and  operating 
procedures  are  not  shown  in  the  figure. 
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Figure  2 Graphical  depiction  of  System  Target  of  Evaluation 


Tide  scope  of  the  STOE  includes  the  technical  and  non-technical  elements  identified  in  Table  1 . 

Table  1 -Scope  of  the  STOE 


STOE  Components 

Example  Hardware/Software  Components 

■ 

Physical  Boundary  Protection 

Access  control  for  ICS  perimeter  and  control  center  security 

Logical  Boundary  Protection 

Firewall  and  other  gateway  security  devices  (e.g.  intrusion  detection 

systems) 

Data  authentication 

Data  authentication  service  performed  by  ICS  components  (e.g. 
authenticators) 

Data  Confidentiality 

Encryption  services,  such  as  link  encryption  devices  between  trusted 
endpoints 
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STOE  Components 


Example  Hardware/Software  Components 


User  Authentication 

User  authentication  service,  integration  with  physical  access  control 

Continuity  of  Operations 

System  backup  and  recovery,  backup  power,  etc 

Operating  procedures 

System  policies  and  procedures  (e.g.  backup  frequency,  password 
requirements,  etc) 

Training 

Security  awareness  & training  courses,  etc. 

Management  procedures 

Staff  selection  criteria,  disciplinary  measures  and  other  relevant  personnel 
security  policies 

2.3  Security  Features 

The  STOE  provides  the  following  security  features: 


Table  2 - Summary  of  STOE  Security  Features 


Feature 

Description 

Authentication 

Authentication  of  the  following: 

" Financial  and  business  critical  information  sent  from  the  ICS  to 
external  systems 

■ Configuration  change  commands  affecting  core  ICS  functions 
(e.g.  control  algorithms,  set  points,  limit  points  etc) 

■ Users  and  services  accessing  the  protected  assets  (e.g.  actuators, 
control  systems,  etc) 

Confidentiality 

Protection  of  business,  financial  and  control  data  from  unauthorized 
disclosure  (as  determined  by  risk  assessment  and  approved  by  the  data 
or  system  owner),  including,  but  not  limited  to,  appropriate  segments 
within  the  ICS  network. 

Integrity 

Protection  against  the  unauthorized  modification  of  the  following 
information: 

■ Information  flows  of  a sensitive  nature  on  exposed  network 
segments 

■ Internal  control  data  used  throughout  the  ICS 

■ ICS  operational  system  configuration 

Availability7 

Protection  against  the  loss  of  availability  of  all  critical  and  major  ICS 
operational  systems  including,  but  not  limited  to, 

1 
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Feature 

Description 

■ Control  servers 

■ Primary  communications  channel  (or  network) 

■ ICS  operational  system  configuration  capability 

Boundary  Protection 

Protection  against  unauthorized  attempts  to  breech  both  the  physical  and 
the  logical  boundaries  of  the  ICS. 

Access  control 

Strict  access  control  for  the  following: 

■ On-site  and  off-site  remote  access  into  the  ICS  network 

■ Extemally-visible  interfaces  of  the  ICS 

■ System  resources  deemed  by  the  owner(s)  as  requiring 
protection 

■ Those  system  functions  capable  of  modifying  ICS  configuration 

■ Critical  ICS  processes  based  on  state  information  relevant  to 
that  process  (e.g.  time  of  day,  location,  etc) 

Backup  / Recovery 

Backup  mechanisms  for  critical  ICS  data  and  control  information  to 
enable  timely  recovery  from  system  compromises  or  damage. 

Audit 

Entries  in  the  audit  log  of  appropriate  ICS  components  detailing  the 
successful  and  unsuccessful  security  relevant  activities  of  users  and 
applications. 

Monitoring 

Monitoring  and  detection  of  unauthorized  activity,  unusual  activity  and 
attempts  to  defeat  the  security  capabilities  of  the  ICS,  including  the 
deployment  of  intrusion  detection  systems  (IDS)  at  critical  parts  of  the 

ICS  infrastructure. 

Non-interference  with  safely 

Non-interference  of  ICS  security  functions  and  safety-critical  functions 

critical  functions 

while  maintaining  ICS  performance. 

Self  Verification 

Self-tests  to  verify  the  configuration  and  integrity  of  the  security 
functions  of  the  ICS. 

Emergency  power 

Emergency  power  sufficient  to  allow  for  graceful  shutdown  of  the  ICS 
and  the  controlled  process  in  the  event  that  primary  and  secondary 
power  fail. 

Security  Plans,  Policies  & 

Security  plans,  policies  and  procedures  covering  at  least  the  following 

Procedures 

areas: 

■ Overarching  security  policy  governing  the  access  and  necessary 
protection  for  all  ICS  components 

■ Security  management  of  the  ICS  and  associated  infrastructure 

■ Security  management  roles  and  responsibilities  throughout  the 
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ICS  management  infrastructure 

■ Documentation  of  the  organizational  risk  management  process 
and  its  relationship  to  ICS  systems 

■ Business  continuity  and  disaster  recovery  plans  for  the  ICS 

■ Migration  Strategy  covering  the  identification,  assessment  and 
treatment  of  new  or  existing  vulnerabilities  (in  accordance  with 
risk  management  policy)  during  the  life-cycle  of  the  ICS 

■ Policies  governing  the  roles,  responsibilities  and  activities 
authorized  for  third  parties  interfacing  with  ICS  components 

■ Policies  and  the  necessary  procedures  to  ensure  adherence  to 
identified  compliance  regulations  (e.g.  System  Audits,  Privacy 
Act,  etc) 

2.4  Features  Outside  of  Scope 

Features  outside  the  scope  of  the  defined  STOE: 

• General  physical  protection  outside  the  scope  of  the  ICS 

• Enterprise  intranet  protection 

• Protection  of  "business"  information  and  systems  other  than  that  generated  by  the  ICS  while 
it  resides  within  the  ICS. 

• Primary  power  sources  (e.g.  mains  generated  supply) 

• General  corporate-level  security  policies,  procedures  and  training  (the  STOE  will  only 
address  ICS  specific  policies,  procedures  and  training) 
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3 STOE  Security  Environment 

In  order  to  clarify  the  nature  of  the  security  problem  that  the  STOE  is  intended  to  solve,  this 
section  describes  the  following: 

• Any  assumptions  about  the  security  aspects  of  the  environment  and/or  of  the  manner  in  which 
the  STOE  is  intended  to  be  used. 

• Any  known  or  assumed  threats  to  the  assets  against  which  specific  protection  within  the  STOE 
or  its  environment  is  required. 

• Any  organizational  security  policy  statements  or  rules  with  which  the  STOE  must  comply. 


3.1  Secure  Usage  Assumptions 


The  following  assumptions  relate  to  the  operation  of  the  TOE: 

Table  3 - Secure  Usage  Assumptions 


Name 

Description 

A.PHYSICALACCESS 

In  accordance  with  organizational  policy  physical  access  controls  are 
applied  at  designated  physical  access  points  throughout  the  system  whose 
perimeters  are  defined  by  the  organization,  and  personnel  with  authorized 
access  is  documented  and  maintained.  Entry  to  secure  areas  is  controlled 
and  monitored  on  a periodic  basis. 

A.COMMSACCESS 

In  accordance  with  organizational  policy,  physical  access  to 
communication  media,  and  connections  to  the  media,  and  services  allowed 
to  go  over  the  communications  media  (e.g.,  internet  access,  e-mail)  is 
controlled,  as  is  access  to  devices  that  display  or  output  system  control 
information. 

A.EXTERNAL 

The  ICS  network  may  have  connectivity  with  non-ICS  system  networks 
through  which  Internet  connectivity  is  possible. 

A.REMOTE 

Remote  access  to  ICS  components  may  be  available  to  authorized  individuals. 

3.2  Threats  to  Security 

Threats  may  be  addressed  either  by  the  STOE  or  by  its  intended  environment  (for  example,  using 
personnel,  physical,  or  administrative  safeguards  not  provided  by  the  STOE).  These  two  classes  of  threats 
are  discussed  separately. 

Threats  are  characterized  in  terms  of  an  identified  threat  agent,  the  attack,  and  the  asset  that  is  the  subject 
of  the  attack.  Threats  agents  are  described  as  a combination  of  expertise,  available  resources,  and 
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motivation.  Attacks  are  described  as  a combination  of  attack  methods,  any  vulnerabilities  exploited,  and 
opportunity. 

3.2.1  Threats  Addressed  by  the  STOE 

The  following  sections  document  the  threat  agents,  attacks  and  assets  relevant  to  the  STOE.  The 
last  section  combines  all  three  aspects  into  a list  of  threats  to  be  countered  by  the  STOE. 

3.2. 1.1  Threat  Agents 

Threats  agents  are  characterized  through  a combination  of  expertise,  available  resources,  and  motivation. 
The  threat  agents  relevant  to  the  STOE  have  been  captured  below  in  Table  4. 


Table  4 - Threat  Agents  for  the  STOE 


Threat  Agent  Label 

. 

' - \ ' c 3 s , ' v*  £ 

Threat  Agent 

AGENT.INSIDER 

Trusted 
employee, 
contractor, 
vendor  or 

customer 

Low/High 

Substantial 

Non-malicious 

AGENT.EVIL  INSIDER 

Trusted 
employee, 
contractor, 
vendor  or 

customer 

acting 

inappropriately 

Low/High 

Substantial 

Malicious 

AGENT.PRIOR  INSIDER 

Former  trusted 
employee, 
contractor, 
vendor  or 

customer 

Low/High 

Moderate 

Malicious 

AGENT.OUTSIDER 

Unauthorized 
external  party 

High 

Minimal/ 

Moderate 

Malicious 

AGENT.NATURE 

Environmental 
sources  of 
threats  such  as 
earthquakes, 
flood  and  fire 

N/A 

Substantial 

N/A 

1 The  descriptions  for  expertise,  resources  and  motivation  correspond  to  those  defined  for  “capability  of  the  attacker",  “resources  of  the  attacker", 
and  "intent  of  the  attacker"  from  Appendix  E of  NIST  Special  Publication  800-53:  Recommended  Security  Controls  for  Federal  Information 
Systems. 
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Evil  insiders  include  those  legitimate  users  on  the  internal  ICS  network  who  misuse  privileges  or 
impersonate  higher-privileged  users. 

Outsiders  include  those  intruders  gaining  access  to  the  ICS  from  the  Internet,  dialup  lines,  physical 
break-ins,  or  from  partner  (supplier  or  customer)  networks  linked  to  the  corporate  network. 

3. 2. 1.2  Attacks 

Attacks  are  described  as  a combination  of  attack  methods,  any  vulnerabilities  exploited,  and  opportunity. 

3.2. 1.2.1  Sources  of  Vulnerability 

The  sources  of  vulnerability  applicable  to  the  STOE  have  been  captured  below.  Please  note  that 
these  sources  of  vulnerability  should  be  further  refined  by  the  SST  author  to  identify  specific 
vulnerabilities  applicable  to  the  their  own  instantiation  of  the  STOE. 

Editor ’s  note:  The  table  below  refers  to  sources  or  categories  of  vulnerabilities  applicable  to  an 
ICS.  It  is  envisaged  that  the  categories  of  vulnerabilities  listed  below  will  be  refined  by  the  SST 
author  as  each  STOE  will  have  vulnerabilities  specific  to  their  own  security  environment  in  which 
the  ICS  is  deployed. 


Table  5 - Sources  of  Vulnerabilities  of  the  STOE 


Vulnerability  Label 

Vulnerability 

V.PLA1NTEXT 

Use  of  clear  text 
protocols 

The  use  of  clear  text  protocols  and  the  transmission 
of  business  and  control  data  unencrypted  over 
insecure  communication  channels  (e.g.  FTP, 
TELNET). 

V.SERVICES 

Unnecessary 
services  enabled 
on  system 
components 

The  presence  of  unnecessary  system  services  on  key 
ICS  components  and  subsystems  that  may  be 
exploited  to  negatively  impact  on  system  security 
(e.g.  sendmail,  finger  services). 

V.REMOTE 

Remote  access 
vulnerabilities 

Uncontrolled  external  access  to  the  corporate 
network  (e.g.  through  the  Internet)  allowing 
unauthorized  entry  to  the  interconnected  ICS 
network.  Also  includes  vulnerabilities  introduced 
through  poor  VPN  configuration,  exposed  wireless 
access  points,  uncontrolled  modem  access  (e.g. 
through  networked  faxes)  and  weak  remote  user 
authentication  techniques. 
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Vulnerability  Label 

Ml— 

V.ARCHITECTURE 

Poor  system 
architecture  design 
leading  to 
weaknesses  in 
system  security 
posture 

Business  and  operational  requirements  impacting  on 
the  effectiveness  of  deployed  or  planned  security 
measures  to  protect  the  confidentiality,  integrity  and 
availability  of  the  ICS  and  its  components.  Poor 
security  architecture  may  also  lead  to  the  bypass  and 
tamper  of  ICS  security  functions. 

V.DEVELOPMENT 

Poor  system 
development 
practices  leading 
to  weakness  in 
system 

implementation 

Lack  of  quality  processes  (e.g.  configuration 
management,  quality  testing)  leading  to  errors  in 
system  implementation  and  third  party  products  such 
as  buffer  overflows  and  errors  in  control  algorithms. 

V.NOPOLICIES 

inadequate  system 
security  policies, 
plans  and 
procedures 

Lack  of  formal  system  policies,  plans  and  procedures 
(e.g.  weak  password  policies,  no  incident  response 
plans,  irregular  compliance  audits,  poor  configuration 
management  policies  and  procedures,  poor  system 
auditing  practices,  backup  procedures  etc). 

V.SPOF 

Single  Points  of 
Failure 

Poor  security  architecture  design  leading  to  one  or 
more  single  points  of  failure  in  the  ICS  and  resulting 
in  system  unavailability. 

V.NOTRAINING 

Inadequate  user 
training 

Inadequate  training  on  system  security  issues  leading 
to  poor  user  security  awareness. 

V.3RDPARTY 

Unauthorized 
access  to  ICS  via 
3rd  party  network 

Unauthorized  user  access  to  the  ICS  or  its 
components  via  a 3rd  party  network  connection. 

V.NOR1SK 

Lack  of  risk 

assessment 

Inadequate  risk  assessment  activities  performed  on 
critical  assets  leading  to  a poor  understanding  of  the 
security  posture  of  the  ICS  and  the  security  controls 
needed  to  counter  security  risks  to  the  organization. 

7 
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Descriptio 


The  generic  types  of  attack  relevant  to  the  STOE  have  been  captured  below.  Please  note  that  the 
referenced  vulnerabilities  have  been  defined  in  the  previous  section. 
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Table  6 - Attack  Methods  against  the  STOE 


- 

Description 

Alibek  JLauel 

Attack 

Method 

fi  ' | | f : . ' 

Vulnerabilities 

■ : • 

Opportunity2 

ATTACK.SNIFF 

Unauthorized 
traffic  analysis 

Packet  capture  tool, 
keystroke  logger 
etc 

V. PLAINTEXT, 

V.  ARCHITECTURE, 
V. REMOTE, 
V.3RDPARTY, 
V.NOR1SK 

Locally  & 

Remotely 

ATTACK.REPLAY 

Unauthorized 
replay  of  captured 
traffic 

Packet  capture  tool, 
keystroke  logger 
etc 

V. PLAINTEXT, 
V.ARCHITECTURE, 
V. REMOTE, 
V.3RDPARTY, 

V. NORISK 

Locally  & 

Remotely 

ATTACK.SPOOF 

Impersonating  an 
authorized  user 

Exploitation  of 
weak  user 
authentication 
mechanism 

V. PLAINTEXT, 

V. REMOTE, 
V.ARCHITECTURE, 
V.NOPOLICIES, 
V.3RDPARTY, 

V. NORISK 

Locally  & 

Remotely 

ATTACK.DOS 

Overloading  the 
network 

Denial  of  service 
attack  from  the 
Internet  causing 
system  downtime 

V. SERVICES, 

V. REMOTE, 

V.ARCHITECTURE, 

V.SPOF, 

V.3RDPARTY, 

V.NORISK 

Remotely 

ATTACK.ERROR 

Operator  error 

ICS  system 
operator  error 
causing  security 
breach 

V. SERVICES, 
V.NOPOLICIES, 
V.NOTRAINING, 
V.NORISK 

Locally 

ATTACK.SOCIAL 

Social  engineering 
of  authorized  users 

Unsolicited  contact 
with  employee 
with  the  intent  of 
discovering  user 
credentials  or 
acquiring  sensitive 
information 

V.NOPOLICIES, 

V.NOTRAINING, 

V.NORISK 

Locally  & 

Remotely 

ATTACK.VIRUS 

Virus  infection  of 
ICS  system 
components 

Virus  propagation 
via  email  system  or 
Internet 
downloaded 
content  (e.g. 

Trojan) 

V. SERVICES, 

V.  REMOTE, 

V.ARCHITECTURE, 

V.NOPOLICIES, 

V.NOTRAINING, 

V.3RDPARTY, 

V.NORISK 

Locally 

“ The  description  for  opportunity  relates  to  whether  the  attack  can  be  conducted  within  the  ICS  network  (locally)  or  outside  the  protected  boundary 
of  the  ICS  network  (remotely). 
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■BpHHn 

Description 

.. 

l 

O' 

Vulnerabilities 

Opportunity2 

ATTACK.DESTROY 

Destruction  of  ICS 
control  data, 
business  data  or 
configuration 
information 

File  deletion  on 
compromised  ICS 
file  servers 

V. SERVICES, 
V.REMOTE, 

V.  ARCHITECTURE, 
V. NOPOLICIES, 
V.NOTRAINING, 

V. NORISK 

Locally  & 

Remotely 

ATTACK.MOD1FY 

Modification  of 

ICS  control  data, 
business  data  or 
configuration 
information 

File  modification 
on  compromised 
ICS  file  servers 

V. SERVICES, 
V.REMOTE, 

V.  ARCHITECTURE. 
V. NOPOLICIES, 
V.NOTRAINING, 

V. NORISK 

Locally  & 

Remotely 

ATT  ACK.BYPASS 

Bypass  of  system 
security  functions 
and  mechanisms 

Modification  of 

ICS  configurations 
of  components 

V. SERVICES, 
V.REMOTE, 

V.  ARCHITECTURE, 
V. NORISK 

Locally  & 

Remotely 

ATTACK.PHYSICAL 

Compromise  of 
poorly 
implemented 
and/or  controlled 
physical  security 
mechanisms 

Unauthorized 

access  to 

physically  secured 
areas  housing 
system  assets  (e.g. 
perimeter  security 
breach) 

V.  ARCHITECTURE, 

V.NOPOLICIES. 

V.NOTRAINING, 

V. NORISK 

Locally 

ATTACK.NATURE 

Acts  of  nature 
causing  system 
unavailability 

Environmental 
occurrences  such 
as  earthquake, 
flood  and  fire 

V.  ARCHITECTURE, 
V.NOPOLICIES, 
V.NOTRAINING 
V.SPOF,  V. NORISK 

Locally 

3.2. 1.3  Assets 


Assets  protected  by  the  STOE  include  the  following: 

Table  7 - Assets  protected  by  the  STOE 


ASSET.ACTUATOR 

Actuator 

One  or  more  devices  that  receive  the 
controlled  variables  from  the  controller  and 
feeds  them  into  the  controlled  process  for 
action. 
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Asset  Label 

Asset 

Description 

ASSET.SENSOR 

Sensor 

One  or  more  devices  that  sense  or  detect  the 
value  of  a process  variable  and  generates  a 
signal  related  to  the  value  (includes  the 
sensing  and  transmitting  parts  of  the  device). 

ASSET.CONTROLLER 

Controller 

The  computer  system  or  components  that 
processes  sensor  input,  executes  control 
algorithms  and  computes  actuator  outputs 
(e.g.  Programmable  Logic  Controllers). 

ASSET.HMI 

HMI 

The  hardware  or  software  through  which  an 
operator  interacts  with  a controller,  providing 
a user  with  a view  into  the  manufacturing 
process  for  monitoring  or  controlling  the 
process. 

ASSET.REMOTE 

Remote 

Diagnostics  & 
Maintenance 

The  hardware  and  software  devices 
responsible  for  diagnostic  and  maintenance 
activities  performed  on  the  ICS  from  remote 
locations  (e.g.  Remote  Terminal  Units, 
pcAnywhere).  May  also  include  the 
communications  mechanism  or  protocol  used 
to  access  to  the  ICS  (e.g.  VPN). 

ASSET.COMMS 

Communications 

Infrastructure 

The  communications  infrastructure  used  to 
bridge  the  control  loop  within  an  ICS.  Also 
includes  the  network  protocols  and  control 
equipment  used  to  integrate  ICS  components 
and  subsystems  (e.g.  Ethernet,  wireless,  RS- 
232  etc). 

ASSET.CTRLPROCESS 

Controlled  Process 

The  process  subject  to  analysis  and  control  by 
the  ICS  (including  the  inputs  and  outputs  to 
the  process). 

ASSET.CTRLINFO 

Process  Control 
Information 

The  process  control  information  being 
collected  by,  processed  by,  stored  on  and 
transmitted  to  or  from  the  components  that 
constitute  the  process  control  network 

ASSET.BUS1NFO 

Process  Control 

Business 

Information 

The  process  control  business  or  financial 
information  being  created  by,  processed  by, 
stored  on  and  transmitted  to  or  from  the 
components  that  constitute  the  process  control 
network. 
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3.2. 1.4  Threat  Description 

Using  the  description  of  the  threat  agents,  attacks  and  assets  captured  in  the  previous  sections,  each  of 
the  threats  relevant  to  the  STOE  have  been  characterized  below: 


Table  8 - Threats  countered  by  the  STOE 


^ 1— — ■ 

T.DISCLOSURE 

\ 

Unauthorized 

Infonnation 

Disclosure 

An  unauthorized  individual  (AGENT.EVIL  INSIDER. 

AGENT. PRIOR  INSIDER.  AGENT.OUTSIDER)  directs  an  attack 
(ATTACK.SNIFF.  ATTACK.SOCIAL)  to  acquire  sensitive 
infonnation  (ASSET.COMMS,  ASSET.CTRLINFO,  • 

ASSET. BUSINFO)  stored  on  ICS  components. 

T.EVIL  ANALYSIS 

Unauthorized 

Analysis 

An  unauthorized  individual  (AGENT.EVIL  INSIDER, 
AGENT.PRIOR  INSIDER,  AGENT.OUTSIDER)  directs  an  attack 
(ATTACK.SNIFF,  ATTACK.SOCIAL)  to  analyze  sensitive 
infonnation  flows  (ASSET.COMMS,  ASSET.CTRLPROCESS, 
ASSET.CTRLINFO,  ASSET.BUSINFO)  protected  by  the  STOE. 

T.EVIL  MODIFICATION 

Unauthorized 

Modification 

An  unauthorized  individual  (AGENT.EVIL  INSIDER, 
AGENT.PRIOR  INSIDER,  AGENT.OUTSIDER)  directs  an  attack 
(ATTACK. MODIFY,  ATTACK. BYPASS,  ATTACK.SNIFF)  to 
modify  sensitive  infonnation  (ASSET.CTRLPROCESS, 
ASSET.CTRLINFO.  ASSET.BUSINFO)  Stored  on  ICS 
components. 

T.EVIL  DESTRUCTION 

Unauthorized 

Destruction 

An  unauthorized  individual  (AGENT.EVIL  INSIDER. 
AGENT.PRIOR  INSIDER,  AGENT.OUTSIDER)  directs  an  attack 
(ATTACK.DESTROY,  ATTACK.BYPASS)  to  destroy  sensitive 
information  (ASSET.CTRLPROCESS,  ASSET.CTRLINFO. 
ASSET.BUSINFO)  stored  on  ICS  components. 

T.CTRLT  AMPER 

Tampering 
with  control 
components 

The  tampering  of  ICS  components  (ASSET. ACTUATOR. 
ASSET.SENSOR.  ASSET.CONTROLLER,  ASSET.HMI, 
ASSET.REMOTE,  ASSET.COMMS)  by  malicious  individuals 
(AGENT.EVIL  INSIDER,  AGENT.PRIOR  INSIDER. 
AGENT.OUTSIDER)  via  the  following  attacks 
(ATTACK. MODIFY,  ATTACK.BYPASS,  ATTACK.PHYSICAL). 

T.BAD  COMMAND 

Integrity  of 
Control 
Commands  ' 

An  authorized  operator  (AGENT.INSIDER)  accidentally  issues 
bad  commands  (ATTACK.ERROR)  resulting  in  the 
modification  of  controlled  ICS  processes  and  components 
(ASSET.CTRLPROCESS,  ASSET. ACTUATOR.  ASSET.SENSOR, 
ASSET.CONTROLLER,  ASSET.HMI). 
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Threat  Label 

Threat 

Description 

T.SPOOF 

Spoofing 
legitimate  users 
of  the  STOE 

An  unauthorized  individual  (AGENT.EVILINSIDER, 

AGENT. PRIOR  INSIDER.  AGENT.OUTSIDER)  directs  an  attack 
(ATTACK.SNIFF,  ATTACK.SPOOF,  ATTACK.SOCIAL)  to  obtain 
user  credentials  (ASSET.REMOTE,  ASSET.COMMS)  stored  on 

ICS  server  components  to  impersonate  authorized  users. 

T.REPUDIATE 

Identity 

repudiation 

An  authorized  user  (AGENT.INSIDER)  denies  having 
performed  an  action  (ATTACK.ERROR)  on  the  ICS  interactive 
systems  (ASSET.REMOTE,  ASSET.COMMS,  ASSET.HMI). 

T.DOS 

Denial  of 

Service 

An  unauthorized  individual  (AGENT.EVIL  INSIDER, 

AGENT. PRIOR  INSIDER,  AGENT.OUTSIDER)  directs  an  attack 
(ATTACK.DESTROY,  ATTACK. DOS)  that  denies  service  to 
valid  users  by  making  ICS  components  (ASSET. ACTUATOR, 
ASSET.SENSOR,  ASSET.CONTROLLER,  ASSET.HMI, 
ASSET.REMOTE,  ASSET.COMMS)  temporarily  unavailable  or 
unusable. 

T.PRIVILEGE 

Elevation  of 
privilege 

An  unprivileged  individual  (AGENT.EVIL  INSIDER, 
AGENT.PRIOR  INSIDER.  AGENT.OUTSIDER)  directs  an  attack 
(ATTACK.ERROR.  ATTACK.SNIFF,  ATTACK.SPOOF, 
ATTACK.SOCIAL)  to  obtain  user  credentials  (ASSET.REMOTE, 
ASSET.COMMS)  stored  on  ICS  server  components  to  elevate 
privileged  access  to  ICS  components  for  malicious 
purposes. 

T.NO  FAULT  RECORD 

Fault 

Detection 

Faults  generated  by  the  system  (AGENT.INSIDER)  as  a 
consequence  of  operator  error  and/or  security  breach 
(ATTACK.ERROR)  while  performing  their  routine  tasks  are 
not  detected  nor  audited  on  ICS  interactive  systems 
(ASSET.REMOTE,  ASSET.COMMS,  ASSET.HMI)  for  further 
analysis  and  correction. 

T.DISASTER 

System 
Unavailability 
due  to  Natural 
Disaster 

A natural  disaster  ( AGENT.NATURE ) ceases  operation  of  one. 
or  more  components  of  the  ICS  (ASSET. ACTUATOR, 
ASSET.SENSOR,  ASSET.CONTROLLER,  ASSET.HMI. 
ASSET.REMOTE,  ASSET.COMMS)  as  a consequence  of 
earthquake,  fire,  flood  or  other  unpredictable  event 
(ATTACK.NATURE). 

T.OUTAGE 

System 
Unavailability 
due  to  Power 
Outage 

A natural  disaster,  malicious  or  non-malicious  individual 
(AGENT.NATURE,  AGENT.INSIDER,  AGENT.EVIL  INSIDER, 
AGENT.PRIOR  INSIDER,  AGENT.OUTSIDER)  inadvertently  (or 
otherwise)  causes  a power  outage  affecting  the  availability 
of  one  or  more  components  of  the  ICS  (ASSET.  ACTUATOR, 
ASSET.SENSOR.  ASSET.CONTROLLER,  ASSET.HMI, 
ASSET.REMOTE,  ASSET.COMMS). 
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T.INFECTION 

Virus  Infection 

An  individual  (AGENT.INSIDER,  AGENT.EVILINSIDER. 
AGENT.PRIORINSIDER,  AGENT.OUTSIDER)  maliciously  or 
accidentally  introduces  a vims  to  the  ICS  network 
(ATTACK. VIRUS)  causing  unnecessary  system  downtime  and 
corruption  of  data  (ASSET. ACTUATOR.  ASSET.SENSOR, 
ASSET.CONTROLLER.  ASSET.HMI,  ASSET.REMOTE. 
ASSET.COMMS,  ASSET.CTRLPROCESS,  ASSET.CTRLINFO, 
ASSET.BUSINFO). 

T.PHYSICALACCESS 

Unauthorized 
physical  access 

An  unauthorized  individual  (AGENT.PRIOR  INSIDER. 
AGENT.OUTSIDER)  directs  an  attack  (ATTACK.PHYSICAL)  to 
gain  physical  access  to  protected  ICS  components 
(ASSET. ACTUATOR.  ASSET.SENSOR.  ASSET.CONTROLLER. 
ASSET.HMI,  ASSET.REMOTE.  ASSET.COMMS). 

2.2 


reats 


This  SPP  has  not  identified  any  threats  relevant  to  the  operating  environment.  Organizational 
security  policy  P. ENVIRONMENT  assumes  that  adequate  security  controls  have  been  deployed  to 
address  the  threats  relevant  to  the  STOE  operating  environment. 

3.3  Overarching  Organizational  Security  Policies 


This  section  describes  the  Overarching  Organizational  Security  Policies  (OOSPs)  that  define  the 
broader  context  of  the  organization  which  support  and  govern  the  use  of  a system.  These  will 
form  part  of  the  basis  for  deriving  the  actual  organizational  security  policies  (OSPs)  to  be  included 
as  part  of  a specific  STOE. 

The  scope  of  organizational  security  policy  includes  both  the  organizational  security  policies  of 
the  organization  that  has  responsibility  for  operating  the  industrial  control  system  as  well  as  those 
for  any  external  organizations  that  the  industrial  control  system  interacts  with.  Security  related 
organizational  policies  include  the  following: 


Name 

. 

P.EVENT 


Table  9 - Organizational  Security  Policies 


■■■ 


Description 


The  organization  shall  monitor  security  events  to  ensure  compliance  with 
security  policies  (e.g.  security  incident  response  plan). 


P.PERSONNEL 


The  organization  shall  have  in  place  policies,  training  programs,  and  reporting 
and  enforcement  mechanisms  such  that  personnel  know  their  security  role  in  the 
organization. 
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Name 

P.INFRASTRUCTURE 

The  organization  shall  provide  an  organizational  structure  to  establish  the 
implementation  of  the  security  program,  in  which  the  policies  can  be  established, 
maintained  and  enforced  throughout  the  organization. 

P.CONFIGURATION 

The  organization  shall  provide  management  and  operational  security  controls 
necessary  to  manage  the  system’s  configuration  during  operations  and  evaluate 
and  control  changes  to  ensure  that  the  system  remains  secure. 

P.PHYSICAL 

Adequate  physical  security  shall  be  provided  to  detect  or  prevent  unauthorized 
access  or  connection  to  the  system  and  its  components. 

P.POLICY 

The  organization  and  system  shall  comply  with  organizational  and  regulatory 
policies  and  controls  governing  the  use  of,  and  implemented  by  the  system  to 
ensure  secure  operations. 

P.ASSETS 

The  organization  shall  provide  documentation  of  the  system  and  its  components, 
to  understand  the  overall  security  posture. 

P.SAFETY 

The  organization  shall  comply  with  relevant  standards  to  ensure  the  safety  of  the 
system  and  its  operators. 

P.NOINTERFERE 

ICS  security  controls  shall  be  implemented  so  as  not  to  impede  the  minimum 
required  operational  capabilities  of  the  ICS,  and  so  as  to  not  impede  the  safety 
systems  that  protect  the  ICS. 

P. BUSINESS 

The  ICS  shall  be  operated  in  accordance  with  a business  continuity  policy  that 
addresses  the  identification  of  and  response  to  events  that  adversely  affect  the 
ability  of  the  ICS  to  operate  in  fulfilling  its  design  goals  (e.g.  power  outages, 
acts  of  nature  etc). 

P.RISK 

The  ICS  shall  be  designed,  implemented,  and  operated  to  meet  the  risk 
objectives  resulting  from  a system  life-cycle  risk  management  program.  The 
risk  management  program  shall  establish  a comprehensive  and  integrated  set  of 
risk  management  goals  for  issues  affecting  ICS  operation,  safety  and  security. 

P. ENVIRONMENT 

The  STOE  operating  environment  shall  have  adequate  security  controls  to 
counter  those  threats  originating  from  outside  of  the  defined  STOE.  The 
implementation  and  maintenance  of  these  security  controls  should  be  in 
accordance  with  organizational  security  policies  similar  to  those  listed  in  this 
table  and  be  selected  based  on  the  outcomes  of  a risk  assessment. 

Name  Description 


System  Protection  Profile  - Industrial  Control  Systems 
Version  1 .0 


Page  28  of  151 


National  Institute  of  Standards  & Technology 
System  Protection  Profile  - Industrial  Control  Systems 


NEST 

Msntorsoi  tswsiioffc  ©t 
Sl»r>dor*l»  and  ‘T»cftnoi»§y 


4 Risks 

The  security  risks  are  a further  instantiation  of  the  security  problem.  The  element  of  risk  is 
captured  by  the  SPP  to  determine  the  relative  importance  of  the  security  needs  of  the  STOE  and  its 
operating  environment.  They  guide  the  specification  of  the  security  objectives  by  ensuring  that 
only  those  security  needs  seen  as  critical  to  the  organization  are  addressed  by  the  STOE  or  its 
operating  environment. 

Each  risk  is  a product  of  asset  value,  assessed  level  of  relevant  threats,  and  associated 
vulnerabilities  (as  identified  in  the  previous  section).  It  represents  the  potential  that  a given  threat 
will  exploit  vulnerabilities  to  cause  loss  or  damage  to  an  asset  or  group  of  assets,  and  hence 
directly  or  indirectly  to  the  organization. 

Please  note  that  this  SPP  has  not  specified  the  level  of  risk.  Rather,  it  is  intended  that  the  SST  author 
evaluate  and  prioritize  the  level  of  each  risk  according  to  their  own  ICS  implementation  (based  on  the 
combination  of  the  value  of  each  asset  to  the  organization,  the  impact  and  probability  rating  of  each 
threat  successfully  exploiting  the  identified  vulnerabilities,  and  the  effectiveness  of  existing  security 
controls).  Further  guidance  on  the  completion  and  relevance  of  this  section  can  be  found  in  chapter  7. 

4.1  Risk  Categories  applicable  to  the  STOE 

The  categories  of  security  risks  relevant  to  the  STOE  are  described  in  Table  1 0.  The  table  references 
the  threats,  vulnerabilities  and  assets  identified  in  the  previous  chapter. 

Editor ’s  Note:  At  this  level  of  abstraction  the  SPP  has  only  captured  the  categories  of  risk  applicable 
to  the  generic  ICS  described  by  this  SPP.  It  is  anticipated  that  future  SPPs  and  SSTs  will  identify 
specific  risks  relevant  to  the  author ’s  own  organizational  context,  and  therefore  expand  upon  the 
generic  risks  presented  in  this  chapter. 


Table  10  - Identified  Risk  Categories  for  the  STOE 


Risk  Category 
Label 


RISK.MANAGE 


Risks  associated  with 
the  security  roles  and 
responsibilities 
applicable  to  all  ICS 
users,  as  well  as  risks 
associated  with  the 
successful 

implementation  of  the 
organizational  security 
policies. 


Threats  Vulnerabilities 


T.BAD  COMMAND, 

T.REPUDIATE, 

T.PRIVILEGE, 

T.NO  FAULT  RECORD. 


V.PLAINTEXT, 

V. SERVICES, 
V.REMOTE, 

V.  ARCHITECTURE 
V.NOPOLICIES. 
V.NOTRAINING, 
V.3RDPARTY 
V. NORISK 


ASSET.  ACTUATOR, 

ASSET.SENSOR. 

ASSET.CONTROLLER, 

ASSET.HMI, 

ASSET.REMOTE, 

ASSET.COMMS, 

ASSET.CTRLPROCESS 
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Risk  Category 
Label 

Risk  Category 
Description 

Threats 

- ■ ; ■ ■ ■'  ' ' : ; ' 

Vulnerabilities  Assets 

. . ....... 

R1SK.SECPOLICY 

Risks  associated  with 
the  development, 
endorsement  and 
maintenance  of  the 
instruction  stipulated 
by  the  corporate 
security  policies. 

T.BAD  COMMAND, 
T.REPUDIATE, 

T.  PRIVILEGE, 

T.NO  FAULT  RECORD. 
T.INFECTION 

V. PLAINTEXT, 

V.SER  VICES, 

V. REMOTE, 

V.ARCHITECTURE 

V.NOPOLICIES, 

V.NOTRAINING, 

V.3RDPARTY 

V. NORISK 

ASSET.  ACTUATOR, 

ASSET.SENSOR, 

ASSET.CONTROLLER, 

ASSET.HMI, 

ASSET.REMOTE, 

ASSET.COMMS, 

ASSET.CTRLPROCESS, 

ASSET.CTRLINFO, 

ASSET.BUSINFO 

RISK.RISKMAN 

Risks  associated  with 
the  management  of  the 
risk  assessment 
processes  for  the  ICS. 

T.DISCLOSURE, 

T.EVIL  ANALYSIS, 

T.EVIL  MODIFICATION, 
T.EVIL  DESTRUCTION, 
T.CTRL  TAMPER, 

T.BAD  COMMAND, 

T.  SPOOF,  T.REPUDIATE, 
T.DOS,  T.PRIVILEGE, 

T.NO  FAULT  RECORD, 
T.DISASTER, 

T.INFECTION, 

T.  PHYSIC  ALACCESS 

V.PLATNTEXT, 

V. SERVICES, 

V. REMOTE, 

V.ARCHITECTURE 

, V.SPOF, 

V.NOPOLICIES, 

V.NOTRAINING, 

V.3RDPARTY 

V. NORISK 

ASSET.  ACTUATOR, 

ASSET.SENSOR, 

ASSET.CONTROLLER, 

ASSET.HMI, 

ASSET.REMOTE, 

ASSET.COMMS, 

ASSET.CTRLPROCESS, 

ASSET.CTRLINFO, 

ASSET.BUSINFO 

RISK.COMPLY 

Risks  associated  with 
not  meeting  internal 
and  statutory 
requirements. 

TBD 

V.ARCHITECTURE 

V.NOPOLICIES, 

V.NOTRAINING, 

V.3RDPARTY 

V.NORISK 

ASSET.  ACTUATOR, 

ASSET.SENSOR, 

ASSET.CONTROLLER, 

ASSET.HMI, 

ASSET.REMOTE, 

ASSET.COMMS, 

ASSET.CTRLPROCESS, 

ASSET.CTRLINFO, 

ASSET.BUSINFO 

R1SK.ASSETCTRL 

Risks  associated  with 
asset  classification, 
labelling,  media 
management  and 
accountability. 

T.REPUDIATE, 

T.PRIVILEGE, 

T.INFECTION, 

T.PHYSICAL  ACCESS 

V.PLAINTEXT, 

V. SERVICES, 

V.REMOTE, 

V.ARCHITECTURE 

V.NOPOLICIES, 

V.NOTRAINING, 

V.3RDPARTY 

V.NORISK 

ASSET.  ACTUATOR, 

ASSET.SENSOR. 

ASSET.CONTROLLER, 

ASSET.HMI, 

ASSET.REMOTE, 

ASSET.COMMS, 

ASSET.CTRLPROCESS, 

ASSET.CTRLINFO, 

ASSET.BUSINFO 
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Risk  Category 
Label 

Risk  Category  Threats 

Description 

1 

1 

Vulnerabilities 

Assets 

RISK.PERSONNEL 

Risks  associated  with 
personnel  vetting, 
security  awareness, 
training,  separation  of 
duties  and  system 
usage  agreements. 

T.BAD  COMMAND, 
T.SPOOF,  T.REPUDIATE, 

T.  PRIVILEGE, 

T.NO  FAULT  RECORD. 

T.  DISASTER. 

T.INEECTION, 

T.PHYSICAL  ACCESS 

V.PLAINTEXT, 

V. SERVICES, 
V.REMOTE, 

V.  ARCHITECTURE 

, V.SPOF, 

V.NOPOLICIES, 

V.NOTRAINING, 

V.3RDPARTY 

V.NORISK 

ASSET.  ACTUATOR. 

ASSET.SENSOR. 

ASSET.CONTROLLER. 

ASSET.HMI. 

ASSET.REMOTE, 

ASSET.COMMS, 

ASSET. CTRLPROCESS. 
ASSET.CTRLINFO. 

ASSET. BUSINFO 

RISK.PHYSICAL 

Risks  associated  with 
unauthorized  physical 
access  and/or  damage 
to  system  components. 

T. PHYSICAL  ACCESS 

V.  ARCHITECTURE 
V.NOPOLICIES, 
V.NOTRAINING, 
V.NORISK 

ASSET.  ACTUATOR. 

ASSET.SENSOR, 

ASSET.CONTROLLER. 

ASSET.HMI, 

ASSET.REMOTE, 

ASSET.COMMS 

RISK.ENV1RON 

Risks  associated  with 
the  effects  of  natural 
disasters,  such  as  fire, 
flood  and  earthquake. 

T.DISASTER 

V.  ARCHITECTURE 

V.SPOF, 

V.NOPOLICIES. 

V.NOTRAINING, 

V.NORISK 

ASSET.  ACTUATOR. 

ASSET.SENSOR. 

ASSET.CONTROLLER. 

ASSET.HMI. 

ASSET.REMOTE. 

ASSET.COMMS, 

ASSET. CTRLPROCESS, 
ASSET.CTRLINFO, 

ASSET. BUSINFO 

RISK.EVIL  ACCESS 

Risks  associated  with 
the  illicit  use, 
modification  and 
destruction  of 
company  data  or 
inappropriate  access  to 
information. 

Risks  associated  w ith 
the  inability  to  make 
individuals 
accountable  for  the 
actions  they  take  w'hen 
using  the  systems. 

T. DISCLOSURE, 

T.EVIL  ANALYSIS, 

T.EVIL  MODIFICATION, 
T.EVIL  DESTRUCTION, 
T.CTRL  TAMPER. 

T.BAD  COMMAND, 
T.SPOOF,  T.REPUDIATE, 
T.DOS.  T.PRIVILEGE, 

T.NO  FAULT  RECORD 

V.PLAINTEXT, 

V. SERVICES, 
V.REMOTE. 

V.  ARCHITECTURE 

, V.SPOF, 

V.NOPOLICIES, 

V.NOTRAINING, 

V.3RDPARTY 

V.NORISK 

ASSET.  ACTUATOR. 

ASSET.SENSOR. 

ASSET.CONTROLLER. 

ASSET.HMI, 

ASSET.REMOTE, 

ASSET.COMMS, 

ASSET. CTRLPROCESS, 
ASSET.CTRLINFO. 

ASSET. BUSINFO 

RISK.NEED2KNOW 

Risks  associated  w ith 
the  threat  to 
information 
confidentiality  and 
privacy,  unauthorised 
disclosure  and  clear 
desk  practices. 

T. DISCLOSURE, 

T.EVIL  ANALYSIS, 
T.SPOOF.  T.PRIVILEGE 

V.PLAINTEXT, 

V. SERVICES, 
V.REMOTE, 

V.  ARCHITECTURE 

V.NOPOLICIES, 

V.NOTRAINING, 

V.3RDPARTY 

V.NORISK 

ASSET.REMOTE, 

ASSET.COMMS, 

ASSET. CTRLPROCESS, 
ASSET.CTRLINFO. 

ASSET. BUSINFO 
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Risk  Category 
Label 

Risk  Category 
Description 

\ ' ■ ' ......  . . •,  \\.  xs  . i ' A"', 

Threats 

i Wc  , ' U T-x  V'E.,v.  ' 

. . • 

Vulnerabilities 

■ ^ ■■ 

Assets 

RISK.INTEGRATE 

Risks  associated  with 
the  integration  of 
security  requirements 
into  the  systems 
development  cycle  and 
the  selection  of  third 
party  products. 

TBD 

V. SERVICES, 

V. REMOTE, 

V . A RCHITECTURE 

, V.SPOF, 

V.NOPOLICIES, 

V.NOTRAINING, 

V.3RDPARTY 

V.NORISK 

ASSET.  ACTUATOR. 

ASSET. SENSOR, 

ASSET.CONTROLLER, 

ASSET.HMI, 

ASSET.REMOTE, 

ASSET.COMMS, 

ASSET.CTRLPROCESS, 

ASSET.CTRLINFO, 

ASSET.BUSINFO 

RISK.NETCOMMS 

Risks  associated  with 
the  protection  of 
network 

communications  at  the 
logical  and  physical 
layers. 

T.DISCLOSURE, 

T.EVIL  ANALYSIS, 

T.CTRL  TAMPER. 

T. SPOOF.  T.DOS, 

T.NO  FAULT  RECORD, 

T.INFECTION, 

T.PHYSICALACCESS 

V. PLAINTEXT, 

V. SERVICES, 
V.REMOTE, 

V.  A RCHITECTURE 

, V.SPOF, 

V.NOPOLICIES, 

V.NOTRAINING, 

V.3RDPARTY 

V.NORISK 

ASSET.  ACTUATOR, 

ASSET. SENSOR, 

ASSET.CONTROLLER, 

ASSET.HMI, 

ASSET.REMOTE, 

ASSET.COMMS, 

ASSET.CTRLPROCESS, 

ASSET.CTRLINFO, 

ASSET.BUSINFO 

R1SK.CONNECT 

Risks  associated  with 
connections  to  other  IT 
systems. 

T.DISCLOSURE, 

T.EVIL  ANALYSIS, 

T.EVIL  MODIFICATION, 
T.EVIL  DESTRUCTION. 
T.CTRL  TAMPER. 

T.SPOOF,  T.DOS, 
T.PRIVILEGE, 

T.NO  FAULT  RECORD, 
T.INFECTION 

V. PLAINTEXT, 

V. SERVICES, 
V.REMOTE, 

V.  ARCHITECTURE 

, V.SPOF, 

V.NOPOLICIES, 

V.NOTRAINING, 

V.3RDPARTY 

V.NORISK 

ASSET.  ACTUATOR, 

ASSET.SENSOR, 

ASSET.CONTROLLER. 

ASSET.HMI. 

ASSET.REMOTE, 

ASSET.COMMS, 

ASSET.CTRLPROCESS, 

ASSET.CTRLINFO, 

ASSET.BUSINFO 

RiSK.INTERNET 

Risks  associated  with 
the  use  of  the  Internet 
and  email  services 
both  internal  and 
external  to  the  ICS. 

T.DISCLOSURE, 

T.EVIL  ANALYSIS, 

T.EVIL  MODIFICATION, 
T.EVIL  DESTRUCTION, 
T.CTRL  TAMPER. 

T.SPOOF,  T.DOS, 
T.PRIVILEGE, 

T.INFECTION 

V.PLAINTEXT, 

V. SERVICES, 

V.REMOTE, 

V.ARCHITECTURE 

, V.SPOF, 

V.NOPOLICIES, 

V.NOTRAINING, 

V.  3RD  PARTY 
V.NORISK 

ASSET.  ACTUATOR, 

ASSET.SENSOR, 

ASSET.CONTROLLER. 

ASSET.HMI, 

ASSET.REMOTE, 

ASSET.COMMS, 

ASSET.CTRLPROCESS, 

ASSET.CTRLINFO, 

ASSET.BUSINFO 

RISK.REMOTE 

Risks  associated  with 
the  connection  of 
remote  users  to  the 

ICS  network. 

T.DISCLOSURE, 

T.EVIL  ANALYSIS, 

T.EVIL  MODIFICATION, 
T.EVIL  DESTRUCTION. 
T.CTRL  TAMPER, 

T.SPOOF,  T.DOS, 
T.PRIVILEGE, 

T.INFECTION 

V.PLAINTEXT, 

V. SERVICES, 

V.REMOTE, 

V.ARCHITECTURE 

, V.SPOF, 

V.NOPOLICIES, 

V.NOTRAINING, 

V.3RDPARTY 

V.NORISK 

ASSET.  ACTUATOR, 

ASSET.SENSOR, 

ASSET.CONTROLLER. 

ASSET.HMI, 

ASSET.REMOTE, 

ASSET.COMMS, 

ASSET.CTRLPROCESS, 

ASSET.CTRLINFO, 

ASSET.BUSINFO 
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Risk  Category 
Label 

Risk  Category 
Description 

Threats 

Vulnerabilities 

* . ' ' ' ' ; , 

Assets 

RISK.ONLINE 

Risks  associated  with 
the  delivery  of  online 
services,  including 
statutory  requirements, 
security  issues  and 
controls,  publishing 
and  third-party 
security. 

T.DISCLOSURE,  T.DOS, 
T.NO  FAULT  RECORD, 

T.  INFECTION 

V.PLAINTEXT, 

V. SERVICES, 

V. REMOTE, 

V.  ARCHITECTURE 

, V.SPOF, 

V.NOPOLICIES, 

V.NOTRAINING, 

V.3RDPARTY 

V.NORISK 

ASSET.  ACTUATOR, 

ASSET.SENSOR, 

ASSET.CONTROLLER. 

ASSET.HMI, 

ASSET.REMOTE, 

ASSET.COMMS, 

ASSET.CTRLPROCESS, 

ASSET.CTRLINFO, 

ASSET.  BUSINFO 

RISK.OPSMANAGE 

Risks  associated  with 
managing  system 
changes,  such  as 
changes  not  approved 
or  audited  correctly, 
lack  of  consultation 
with  relevant  parties, 
loss  of  skilled  people, 
and  lack  of  correct 
documentation. 

Risks  associated  with 
the  use  of  technology 
for  data  and  system 
control,  including  data 
protection,  backup, 
disaster  recovery, 
inadequate  security, 
and  insufficient 
capacity,  etc. 

T.DISCLOSURE, 

T.EVIL  ANALYSIS, 

T.EVIL  MODIFICATION, 
T.EVIL  DESTRUCTION, 
T.CTRL  TAMPER, 

T.BAD  COMMAND. 
T.SPOOF,  T.REPUDIATE, 
T.DOS.  T.PRIVILEGE, 

T.NO  FAULT  RECORD. 
T.DISASTER, 

T.INFECTION, 

T.PHYSICALACCESS 

V.PLAINTEXT, 

V. SERVICES, 
V.REMOTE, 

V.  ARCHITECTURE 

, V.SPOF, 

V.NOPOLICIES, 

V.NOTRAINING, 

V.3RDPARTY 

V.NORISK 

ASSET.  ACTUATOR, 

ASSET.SENSOR. 

ASSET.CONTROLLER. 

ASSET.HMI, 

ASSET.REMOTE, 

ASSET.COMMS, 

ASSET.CTRLPROCESS, 

ASSET.CTRLINFO, 

ASSET. BUSINFO 

RISK.IDS 

Risks  associated  with 
security  auditing, 
security  breach 
detection  and 
response,  incident 
reporting  and  forensic 
evidence  requirements. 

T.BAD  COMMAND, 
T.REPUDIATE, 

T.NO  FAULT  RECORD, 

V. SERVICES, 
V.NOPOLICIES, 
V.NOTRAINING, 
V.NORISK 

ASSET.  ACTUATOR. 

ASSET.SENSOR, 

ASSET.CONTROLLER. 

ASSET.HMI, 

ASSET.REMOTE, 

ASSET.COMMS, 

ASSET.CTRLPROCESS 

RISK.CONTINUITY 

Risks  associated  with 
ensuring  the 
uninterrupted 
availability  of  all  key 
business  resources 
required  to  support 
essential  (or  critical) 
business  activities. 

T.EVIL  DESTRUCTION, 
T.CTRL  TAMPER, 

T.BAD  COMMAND, 

T.DOS,  T.DISASTER, 
T.INFECTION, 

T.PHYSICAL  ACCESS 

V.PLAINTEXT, 

V. SERVICES, 
V.REMOTE, 

V.  ARCHITECTURE 

, V.SPOF, 

V.NOPOLICIES, 

V.NOTRAINING, 

V.3RDPARTY 

V.NORISK 

ASSET.  ACTUATOR, 

ASSET.SENSOR, 

ASSET.CONTROLLER. 

ASSET.HMI, 

ASSET.REMOTE, 

ASSET.COMMS, 

ASSET.CTRLPROCESS, 

ASSET.CTRLINFO, 

ASSET. BUSINFO 
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4.2  Risks  to  the  External  Operating  Environment 

This  SPP  has  not  identified  any  risks  relevant  to  the  external  operating  environment. 
Organizational  security  policy  P. ENVIRONMENT  assumes  that  adequate  security  controls  have 
been  deployed  to  mitigate  the  risks  to  the  STOE  external  operating  environment. 
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5 Security  Objectives 

The  security  objectives  are  a concise  statement  of  the  intended  response  to  the  security  problem.  These 
objectives  indicate,  at  a high  level,  how  the  security  problem,  as  characterized  in  the  "Security 
Environment"  section  of  the  SPP,  is  to  be  addressed.  Just  as  some  threats  are  to  be  addressed  by  the 
STOE  and  others  by  its  intended  environment,  some  security  objectives  are  for  the  STOE  and  others  are 
for  its  environment.  These  two  classes  of  security  objectives  are  discussed  separately. 


5.1  Security  Objectives  for  the  STOE 

The  security  objectives  for  the  STOE  are  as  described  in  the  following  table. 

Table  11  - Security  Objectives  for  the  STOE 


■ ' : : " 


O. PHYSICAL 


Objective  Label 


Ob 


Objective  Description 


tion 


The  STOE  must  provide  protection  at  the  physical  boundaries  of 
the  ICS  to  prevent  access  to  the  protected  assets  by  unauthorized 
users. 


O.RISK 


O.NON  INTERFERENCE 


ICS  risk  assessment  shall  be  conducted  throughout  the  life-cycle 
of  an  ICS,  such  that  a documented  and  approved  risk  assessment 
process  is  conducted  initially,  and  reviewed  with  each  change  to 
the  manufacturing  process  or  change  to  the  ICS;  and  to  ensure  that 
changing  vulnerabilities  do  not  degrade  the  security  of  the  ICS. 


The  ICS  security  functions  shall  be  implemented  in  a non- 
interfering manner  such  behavior  of  the  ICS  functions  and  safety 
functions  are  able  to  meet  their  performance  constraints. 


O.INTERCONNECTIVITY 


ICS  security  functions  shall  include  the  capability  to  secure 
interfaces  and  interconnectivity  of  ICS  related  safety  systems,  as 
required. 


O.DATA  BACKUP 


The  STOE  must  include  provisions  for  ICS  data  and  control 
information  (including  executable  software  and  control  data)  to 
assure  the  ability  for  timely  recovery  to  an  operating  state  if  the 
ICS  is  compromised  or  damaged.  The  data  backup  procedures 
should  follow  industry  best  practices  including  (but  not  limited  to) 
secondary  storage  locations,  testing  of  recovery  procedures,  and  a 
back  up  interval  either  driven  by  configuration  changes  or  a 
specified  time  interval  or  a combination  of  both. 


O.DATA  AUTHENTICATION 


The  STOE  shall  authenticate  configuration  change  commands  such 
that  configuration  (control  algorithms,  set  points,  limit  points,  etc.) 
cannot  be  changed  unless  the  origin  of  the  command  can  be 
positively  established. 

The  STOE  shall  authenticate  financial  or  other  business  critical 
information  sent  from  the  STOE  to  external  systems. 
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Objective  Label 


Objective  Description 


O. CONTINUITY 

The  ICS  shall  ensure  continuity  of  operations  in  accordance  with  a 
business  continuity  policy  that  addresses  a known  set  of 
anticipated  events  that  might  adversely  affect  the  operational 
capability  of  the  ICS. 

O.MANAGEMENT 

A policy  for  governing  security  shall  be  defined  to  establish  the 
following: 

■ An  organization-wide,  security  management  infrastructure 

■ Identified  roles  and  responsibilities,  together  with  explicit 
authority  to  ensure  operational  security  within  the  management 
infrastructure 

O. MIGRATION 

The  ICS  shall  have  a migration  strategy  providing  the  capability  to 
govern  the  evolution  of  the  control  system  throughout  its  security 
operational  life  cycle.  The  migration  strategy  shall  address  at  a 
minimum: 

Assessment  of  new  vulnerabilities  and  appropriate/necessary 
mitigating  actions  to  control/reduce  new  vulnerabilities.  This  may 
include  maintenance  of  the  current  system  state  (components, 
configuration,  patches,  etc). 

The  integration  between  computer  implemented  and  personnel 
implemented  procedures. 

O. COMPLIANCE 

The  ICS  shall  be  operated  in  compliance  with  relevant  governing 
mandates. 

0.3RDPARTY 

Policies  governing  the  roles,  responsibilities  and  activities 
authorized  for  individuals  not  employed  by  the  control  system 
operating  organization  shall  be  developed. 

O.REMOTE 

The  policies  shall  establish  methods  for  on-site  internal,  on-site 
remote,  and  off-site  remote  access  to  control  system  resources. 
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Objective  Label 


O.ACCESS  CONTROL 


■IP 


The  ICS  shall  provide  the  capability  to  grant  or  deny  access  to 
control  system  resources  based  upon  the  action  being  performed, 
and  the  authorizations  associated  with  authorized  subjects. 

The  ICS  shall  deny  unauthorized  agents  access  to  every  control 
system  resource. 

The  ICS  shall  require  that  each  agent  authorized  to  use  the  control 
system  is  identified  and  is  provided  with  credentials  to  authenticate 
their  identity. 

The  ICS  must  be  able  to  include  knowledge  of  the  control  system 
state  and/or  the  controlled  process  state  when  making  an  access 
control  decision. 

The  ICS  shall  include  knowledge  of  time  and  location  in  the  rules 
for  making  an  access  control  decision. 


O.SECURECOMMS 

The  ICS  shall  provide  the  capability  to  prevent  or  detect,  as 
required,  the  loss  of  integrity  of  the  ICS  operational 
communications  capability. 

The  ICS  shall  provide  the  capability  to  allow  information  flows 
only  between  those  endpoints  authorized  by  the  system. 

O.DATAINTEGRITY 

The  ICS  shall  provide  the  capability  to  protect  information  Hows 
from  replay,  substitution  or  modification. 

The  ICS  shall  provide  the  capability  to  allow  the  recipient  of  an 
authorized  information  flow  to  verify  the  correctness  of  the 
received  information. 

O.CONFIDENTIALITY 

The  ICS  shall  protect  the  confidentiality  of  information  determined 
by  the  respective  owners  as  requiring  protection,  including,  but  not 
limited  to,  information  related  to  business,  financial  and  control 
data. 

O.  AVAILABILITY 

The  ICS  shall  have  continuity  of  availability  for  operational 
capability. 

The  ICS  shall  be  capable  of  continuing  operation  if  a control 
server  is  unavailable  for  any  reason. 

The  ICS  shall  be  capable  of  continuing  operation  if  the  primary 
communications  channel  is  unavailable  for  any  reason. 
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Objective  Label 

. 

Objective  Description 

O.SYSTEMINTEGRITY 

The  ICS  shall  provide  the  capability  to  prevent  or  detect,  as 
required,  the  loss  of  integrity  of  the  ICS  operational  system 
configuration  and  capability. 

The  ICS  shall  provide  the  capability  to  restrict  access  to  the 
functions  used  to  establish  and  maintain  the  secure  operational 
configuration  of  the  ICS. 

O.SYSTEM  DIAGNOSTICS 

The  ICS  shall  be  capable  of  performing  self-tests  to  verify  the 
configuration  and  integrity  of  the  security  functions  of  the  ICS.  . 

The  ICS  shall  provide  the  capability  for  self-test  to  be  executed  on 
start-up,  at  periodic  intervals,  and  on  demand. 

O. MONITORING 

The  ICS  shall  be  capable  of  detecting  unauthorized  activity, 
unusual  activity  and  attempts  to  defeat  the  security  capabilities  of 
the  ICS. 

O. AUDIT 

The  ICS  shall  provide  the  capability  to  record  and  maintain  event 
traces  that  reflect  the  successful  and  unsuccessful  security  relevant 
activities  involving  ICS  resources. 

O.IDS 

The  ICS  shall  be  capable  of  detecting  unauthorized  activity, 
unusual  activity  and  attempts  to  defeat  the  security  capabilities  of 
the  ICS. 

The  control  system  shall  be  capable  of  initiating  action  in  response 
to  the  detection  of  a potential  violation  of  the  ICS  security  policy. 

5.2  Security  Objectives  for  the  External  Operating  Environment 

This  SPP  has  not  identified  any  security  objectives  relevant  to  the  external  operating  environment. 
Organizational  security  policy  P. ENVIRONMENT  assumes  that  adequate  security  controls  have 
been  deployed  to  address  the  security  needs  outside  the  scope  of  the  STOE. 
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6 IT  Security  Requirements 

6.1  STOE  Security  Functional  Requirements 

This  section  contains  the  functional  requirements  for  the  STOE.  This  includes  system  security 
functional  requirements  and  system  security  assurance  requirements.  The  requirements 
are  primarily  stated  as  logical  requirements  and  cover  information  technology  related 
requirements,  requirements  for  system  security  policies  and  system  security  related 
operating  procedures,  and  integration  requirements  addressing  interfaces  and 
interoperability  between  security  system  components.  The  functional  requirements  are  listed 
in  summary  form  in  the  table  below. 

Editor’s  Note:  Table  12  and  the  text  below  it  outline  extensions  to  the  functional 
requirements  that  is  building  on  ISO  system  work  in  concert  with  NIST  work  building  on 
security  controls. 


Table  12  - STOE  Security  Functional  Requirements 


Component 


Component  Name 


Class  FAU:  Audit 


1 

FAU  ARP.l 

Security  alarms 

2 

FAU  GEN.l 

Audit  data  generation 

3 

FAU  GEN.2 

User  identity  association 

4 

FAU  SAA.l 

Potential  violation  analysis 

5 

FAU  SAA.2 

Profile  based  anomaly  detection 

6 

FAU  SAA.3 

Simple  attack  heuristics 

7 

FAU  SAA.4 

Complex  attack  heuristics 

8 

FAU  SAR.l 

Audit  review 

9 

FAU  SAR.2 

Restricted  audit  review 

10 

FAU  SARA 

Selectable  audit  review 

11 

FAU  STG.l 

Protected  audit  trail  storage 

12 

FAU  STG.2 

Guarantees  of  audit  data  availability 

13 

FAU  STG.3 

Action  in  case  of  possible  audit  data  loss 

14 

FAU  STG.4 

Prevention  of  audit  data  loss 

15 

FAU  SEL.l 

Selective  audit 
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No. 

Component 

Component  Name 

Class  FCS:  Cryptographic  support 

16 

FCS  CKM.4 

Cryptographic  key  management 

17 

FCS  COP.l 

Cryptographic  operation 

Class  FDP:  User  data  protection 

18 

FDP  ACC.  1 

Subset  access  control 

19 

FDP  ACC.2 

Complete  access  control 

20 

FDP  ACF.l 

Security  attribute  based  access  control 

21 

FDP  DAU.2 

Data  authentication 

22 

FDP  IFC.l 

Subset  information  flow  control 

23 

FDP  IFC.2 

Complete  information  flow  control 

24 

FDP  IFF.l 

Simple  security  attributes 

25 

FDP  UCT.l 

Basic  data  exchange  confidentiality 

26 

FDP  UIT.l 

Data  exchange  integrity 

27 

FDP  UIT.2 

Source  data  exchange  recovery 

Class  FEM 

Event  Monitoring 

28 

FEM  EDI.l 

Event  Definition  and  Identification 

29 

FEM  EDI. 2 

Interaction  of  System  Event  Monitoring  Components 

30 

FDM  EDI. 3 

Alarm  Audit  Requirements 

31 

FEM  EDI.4 

Alarm  Respoonse 

Class  FIA:  Identification  & Authentication 

32 

FIA  AFL.l 

Authentication  failure  handling 

33 

FIA  ATD.l 

User  attribute  definition 

34 

FIA  SOS.l 

Verification  of  passwords 

35 

FIA  SOS.2 

TSF  generation  of  passwords 

36 

FIA  UAU.l 

Timing  of  authentication 

37 

FIA  UAU.2 

User  authentication  before  any  action 

38 

FIA  UAU.3 

Unforgeable  authentication 

39 

FIA  UAU.4 

Single  use  authentication  mechanisms 

40 

— 

FIA  UAU.7 

Protected  authentication  feedback 

41 

FIA  UID.l 

Timing  of  identification 

Nbl 
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No. 

. ' ■ ■ ■ ■ ' ' . 

Component  Component  Name 

42 

FIA  UID.2 

User  identification  before  any  action 

Class  FMT:  Management  of  functions  in  TSF 

43 

FMT  MOF.l 

Management  of  security  functions  behavior 

44 

FMT  MOF.2 

Security  function  and  security  policy  mapping 

45 

FMT  MSA.l 

Management  of  security  attributes 

46 

FMT  MTD.l 

Management  of  TSF  data 

47 

FMT  MTD.4' 

Management  of  TSF  data  to  policy  mapping 

48 

FMT  REV.l 

Revocation 

49 

FMT  SAE.l 

Time  limited  authorization 

50 

FMT  SMF.l 

Security  management  functions 

51 

FMT  SMR.l 

Security  roles 

52 

FMT  SMR.2 

Restrictions  on  security  roles 

53 

FMT  SMR.4 

Security  role  to  policy  mapping 

Class  FEM:  Security  event  monitoring 

54 

FEM  EDI.l 

Event  definition  and  identification 

55 

FEM  EDI. 2 

Interaction  of  system  event  monitoring  components 

56 

FEM  EDI. 3 

Alarm  audit  requirements 

57 

FEM  EDI.4 

Alarm  response 

Class  FPT: 

Protection  of  the  TSF 

58 

FPT  AMT.l 

Abstract  machine  testing 

59 

FPT  FLS.l 

Failure  with  preservation  of  secure  state 

60 

FPT  ITA.l 

Inter-TSF  availability  within  a defined  availability  metric 

61 

FPT  ITC.l 

Inter-TSF  confidentiality  during  transmission 

62 

FPT  ITI.l 

Inter-TSF  detection  of  modification 

63 

FPT  ITI.2 

Inter-TSF  detection  and  correction  of  modification 

64 

FPT  PHP.l 

Passive  detection  of  physical  attack 

65 

FPT  PHP.2 

Notification  of  physical  attack 

66 

FPT  PHP.3 

Resistance  to  physical  attack 

67 

FPT  PHP.4 

Domain  definition  and  alarm  response 

68 

FPT  RCV.2 

Automated  recovery 
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No. 

Component 

Component  Name 

■ ■ ' ■ . • 

69 

FPT  RCV.3 

Automated  recovery  without  undue  loss 

70 

FPT  RCV.4 

Function  recovery 

71 

FPT  RCV.5 

Continuous  degraded  operations 

72 

FPT  RPL.l 

Replay  detection 

73 

FPT  SEP.l 

TSF  domain  separation 

74 

FPT  SSP.l 

Simple  trusted  acknowledgement 

75 

FPT  SSP.2 

Mutual  trusted  acknowledgement 

76 

FPT  STMT 

Reliable  time  stamps 

77 

FPT  TDC.l 

Inter-TSF  data  consistency 

78 

FPT  TRC.l 

Internal  TSF  consistency 

79 

FPTTST.l 

TSF  testing 

Class  FCM:  Protection  of  System  Configuration 

80 

FCM  IDI.l 

Identification  information 

81 

FCMJDI.2 

Change  requests  and  actions 

82 

FCMIDI.3 

Authorizations 

Class  FRU:  Resource  utilization 

83 

FRUFLT.l 

Degraded  fault  tolerance 

84 

FRUPRS.l 

Limited  priority  of  service 

85 

FRUPRS.2 

Full  priority  of  service 

Class  FTP:  Trusted  path/channels 

86 

FTPITC.l 

Inter-TSF  trusted  channel 

87 

FTPTRP.l 

Trusted  path 

The  following  sections  contain  the  functional  components  from  the  Common  Criteria  Part  2 
[CC2]  (CC)  with  the  operations  completed.  The  standard  CC  text  is  in  regular  font;  the  text 
inserted  by  the  System  Protection  Profile  (SPP)  author  is  in  accordance  with  the  conventions 
described  in  at  the  beginning  of  this  document. 
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FIAUID.l  Timing  of  identification 

Hierarchical  to:  No  other  components. 

FIA  UID.1.1  The  TSF  shall  allow  [assignment:  list  of  TSF -mediated  actions ] on  behalf 
of  the  user  to  be  performed  before  the  user  is  identified. 

FIA  UID.1.2  The  TSF  shall  require  each  user  to  be  successfully  identified  before 
allowing  any  other  TSF-mediated  actions  on  behalf  of  that  user. 

Dependencies:  No  dependencies 

FIAUAU.l  Timing  of  authentication 

Hierarchical  to:  No  other  components. 

FIAUAIJ.1.1  The  TSF  shall  allow  [assignment:  list  of  TSF  mediated  actions ] on  behalf 
of  the  user  to  be  performed  before  the  user  is  authenticated. 

FIA  UAU.1.2  The  TSF  shall  require  each  user  to  be  successfully  authenticated  before 
allowing  any  other  TSF-mediated  actions  on  behalf  of  that  user. 

Dependencies:  FIA  UID.l  Timing  of  identification 

FIAUAU.2  User  authentication  before  any  action 

Hierarchical  to:  FIA  UAU.l 

FIA  UAU.2.1  The  TSF  shall  require  each  user  to  be  successfully  authenticated  before 
allowing  any  other  TSF-mediated  actions  on  behalf  of  that  user. 

Dependencies:  FIA  UID.l  Timing  of  identification 

FIA  AFL.l  Authentication  failure  handling 

Hierarchical  to:  No  other  components. 

FIA  AFL.l. 1 The  TSF  shall  detect  when  [assignment:  number ] unsuccessful 
authentication  attempts  occur  related  to  [assignment:  list  of  authentication  events]. 

FIA  AFL.1.2  When  the  defined  number  of  unsuccessful  authentication  attempts  has 
been  met  or  surpassed,  the  TSF  shall  [assignment:  list  of  actions]. 

Dependencies:  FIA  UAU.l  Timing  of  authentication 

FTP  TRP.l  Trusted  path 

Hierarchical  to:  No  other  components. 

FTP  TRP.l. 1 The  TSF  shall  provide  a communication  path  between  itself  and 
[selection:  remote , local]  users  that  is  logically  distinct  from  other  communication 
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paths  and  provides  assured  identification  of  its  end  points  and  protection  of  the 
communicated  data  from  modification  or  disclosure. 

FTP  TRP.1.2  The  TSF  shall  permit  (selection:  the  TSF , local  users , remote  users]  to 
initiate  communication  via  the  trusted  path. 

FTP  TRP.1.3  The  TSF  shall  require  the  use  of  the  trusted  path  for  (selection:  initial 
user  authentication , (assignment:  other  services  for  which  trusted  path  is  required]. 
Dependencies:  No  dependencies 

FTATSE.l  TOE  session  establishment 

Hierarchical  to:  No  other  components. 

FTA  TSE.l.l  The  TSF  shall  be  able  to  deny  session  establishment  based  on 
(assignment:  attributes]. 

Dependencies:  No  dependencies 


Password  Selection 


FIA  SOS.l  Verification  of  passwords 

Hierarchical  to:  No  other  components. 

FIA  SOS.1.1  The  TSF  shall  provide  a mechanism  to  verify  that  passwords  meet 
(assignment:  a defined  quality  metric]. 

Dependencies:  No  dependencies 

FIA  SOS.2  TSF  Generation  of  passwords 

Hierarchical  to:  No  other  components. 

FIA  SOS.2.1  The  TSF  shall  provide  a mechanism  to  generate  passwords  that  meet 
(assignment:  a defined  quality  metric]. 

FIA  SOS.2.2  The  TSF  shall  be  able  to  enforce  the  use  of  TSF  generated  passwords  for 
(assignment:  list  of  TSF  functions ]. 

Dependencies:  No  dependencies 

FMT  SAE.l  Time-limited  authorisation 

Hierarchical  to:  No  other  components. 

FMT  SAE.1.1  The  TSF  shall  restrict  the  capability  to  specify  an  expiration  time  for 
(assignment:  list  of  security  attributes  for  which  expiration  is  to  be  supported]  to 
(assignment:  the  authorized  identified  roles]. 

FMT  SAE.1.2  For  each  of  these  security  attributes,  the  TSF  shall  be  able  to 
(assignment:  list  of  actions  to  be  taken  for  each  security  attribute]  after  the  expiration 
time  for  the  indicated  security  attribute  has  passed. 

Dependencies:  FMT_SMR.l  Security  roles 
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FIA  UAU.7  Protected  authentication  feedback 

Hierarchical  to:  No  other  components. 

FIA  UAU.7.1  The  TSF  shall  provide  only  [assignment:  list  of  feedback | to  the  user 
while  the  authentication  is  in  progress. 

Dependencies:  FIAUAU.l  Timing  of  authentication 

(For  passwords) 


FMTMTD.l  Management  of  TSF  data 

Hierarchical  to:  No  other  components. 

FMT  MTD.l.l  The  TSF  shall  restrict  the  ability  to  [selection:  change  default  query , 
modify,  delete,  clear , [assignment:  other  operations]]  the  [assignment:  list  of  TSF 
data]  to  [assignment:  the  authorized  identified  roles]. 

Dependencies:  FMTSMF.l  Specification  of  management  functions 
FMTSMR.l  Security  roles 


FPTRPL.l  Replay  detection 

Hierarchical  to:  No  other  components. 

FPT  RPL.1.1  The  TSF  shall  detect  replay  for  the  following  entities:  [assignment:  list 
of  identified  entities]. 

FPTRPL.1.2  The  TSF  shall  perform  [assignment:  list  of  specific  actions]  when  replay 
is  detected. 

Dependencies:  No  dependencies 


FIA  UAU.3  Unforgeable  authentication 

Hierarchical  to:  No  other  components. 

FIA_UAL.3.l  The  TSF  shall. [selection:  detect,  prevent]  use  of  authentication  data  that 
has  been  forged  by  any  user  of  the  TSF. 

FIA  UAU.3.2  The  TSF  shall  [selection:  detect,  prevent]  use  of  authentication  data  that 
has  been  copied  from  any  other  user  of  the  TSF. 

Dependencies:  No  dependencies 

FIA  UAU.4  Single-use  authentication  mechanisms 

Hierarchical  to:  No  other  components. 

FIA  UAU.4.1  The  TSF  shall  prevent  reuse  of  authentication  data  related  to 
[assignment:  identified  authentication  mechanism(s)]. 

Dependencies:  No  dependencies 

—These  are  targeted  to  preventing  replay  attacks  from  captured  control  signals— 
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FTASSL.l  TSF-initiated  session  locking 

Hierarchical  to:  No  other  components. 

FT  A SSL.l.l  The  TSF  shall  lock  an  interactive  session  after  [assignment:  time  interval 
of  user  inactivity ] by: 

a)  clearing  or  overwriting  display  devices,  making  the  current  contents  unreadable; 

b)  disabling  any  activity  of  the  user’s  data  access/display  devices  other  than 
unlocking  the  session. 

FTA  SSL.1.2  The  TSF  shall  require  the  following  events  to  occur  prior  to  unlocking 
the  session:  [assignment:  events  to  occur]. 

Dependencies:  FIAUAU.l  Timing  of  authentication 
FTASSL.2  User-initiated  locking 
Hierarchical  to:  No  other  components. 

FTA  SSL.2.1  The  TSF  shall  allow  user-initiated  locking  of  the  user’s  own  interactive 

session, 

by: 

a)  clearing  or  overwriting  display  devices,  making  the  current  contents  unreadable; 

b)  disabling  any  activity  of  the  user’s  data  access/display  devices  other  than 
unlocking  the  session. 

FTA  SSL.2.2  The  TSF  shall  require  the  following  events  to  occur  prior  to  unlocking 
the  session:  [assignment:  events  to  occur]. 

Dependencies:  FIAUAU.l  Timing  of  authentication 
FTA  SSL.3  TSF-initiated  termination 
Hierarchical  to:  No  other  components. 

FTA  SSL.3.1  The  TSF  shall  terminate  an  interactive  session  after  a [assignment:  time 
interval  of  user  inactivity ]. 

Dependencies:  No  dependencies 


FMTMTD.l  Management  of  TSF  data 

Hierarchical  to:  No  other  components. 

FMT  MTD.l.l  The  TSF  shall  restrict  the  ability  to  [selection:  change  default,  query , 
modify , delete , clear , [assignment:  other  operations]]  the  [assignment:  list  of  TSF 
data]  to  [assignment:  the  authorized  identified  roles]. 

Dependencies:  FMT  SMF.l  Specification  of  management  functions 
FMT  SMR.l  Security  roles 

(User  accounts  and  User  profiles) 
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FIAATD.l  User  attribute  definition 

Hierarchical  to:  No  other  components. 

FIA  ATD.1.1  The  TSF  shall  maintain  the  following  list  of  security  attributes 
belonging  to  individual  users:  [assignment:  list  of  security  attributes |. 
Dependencies:  No  dependencies 

(Definition  of  user  security  attributes  contained  in  a user  profile) 


6.1.7  Role  based  access  control 

FDPACC.l  Subset  access  control 

Hierarchical  to:  No  other  components. 

FDP  ACC. l.l  The  TSF  shall  enforce  the  [assignment:  access  control  SFP\  on 
[assignment:  list  of  subjects,  objects , and  operations  among  subjects  and  objects 
covered  by  the  SFP\. 

Dependencies:  FDPACF.l  Security  attribute  based  access  control 

FDP  ACC.2  Complete  access  control 

Hierarchical  to:  FDP  ACC.l 

FDPACC.2.1  The  TSF  shall  enforce  the  [assignment:  access  control  SFP ] on  [assignment: 
list  of  subjects  and  objects]  and  all  operations  among  subjects  and  objects  covered  by 
the  SFP. 

FDP  ACC.2.2  The  TSF  shall  ensure  that  all  operations  between  any  subject  in  the 
TSC  and  any  object  within  the  TSC  are  covered  by  an  access  control  SFP. 

Dependencies:  FDP  ACF.l  Security  attribute  based  access  control 

FDP  ACF.l  Security  attribute  based  access  control 

Hierarchical  to:  No  other  components. 

FDP  ACF.l. 1 The  TSF  shall  enforce  the  [assignment:  access  control SFP\  to  objects 
based  on  [assignment:  security  attributes,  named  groups  of  security  attributes |. 

FDP  ACF.1.2  The  TSF  shall  enforce  the  following  rules  to  determine  if  an  operation 
among  controlled  subjects  and  controlled  objects  is  allowed:  [assignment:  rules 
governing  access  among  controlled  subjects  and  controlled  objects  using  controlled 
operations  on  controlled  objects]. 

FDP  ACF.1.3  The  TSF  shall  explicitly  authorize  access  of  subjects  to  objects  based  on 
the  following  additional  rules:  [assignment:  rules , based  on  security  attributes , that 
explicitly  authorize  access  of  subjects  to  objects ]. 

FDP  ACF.1.4  The  TSF  shall  explicitly  deny  access  of  subjects  to  objects  based  on  the 
[assignment:  rules,  based  on  security  attributes,  that  explicitly  deny  access  of  subjects 
to  objects ]. 

Dependencies:  FDP  ACC.l  Subset  access  control 
FMT  MSA.3  Static  attribute  initialization 
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FMTSMR.l  Security  roles 

Hierarchical  to:  No  other  components. 

FMT  SMR.l.l  The  TSF  shall  maintain  the  roles  [assignment:  the  authorized  identified 
roles] . 

FMT  SMR.1.2  The  TSF  shall  be  able  to  associate  users  with  roles. 

Dependencies:  FIAUID.l  Timing  of  identification 

FMTSMR.2  Restrictions  on  security  roles 

Hierarchical  to:  FMT  SMR.l 

FMT  SMR.2.1  The  TSF  shall  maintain  the  roles:  [assignment:  the  authorized  identified 
roles]. 

FMT  SMR.2.2  The  TSF  shall  be  able  to  associate  users  with  roles. 

FMT  SMR.2.3  The  TSF  shall  ensure  that  the  conditions  | assignment:  a single  user 
account  is  not  assigned  the  two  different  roles  associated  with  a two-man  rule \ are 
satisfied. 

Dependencies:  FIA  UID.l  Timing  of  identification 

Application  Note:  FDP  ACF.l  may  be  used  to  specify  that  particular  operations  require 
two  distinct  roles  to  authorize  the  action.  FMT  SMR.2.3  can  ensure  that  a user  account 
cannot  be  assigned  to  both  roles  (as  used  above).  If  there  is  more  than  one  situation 
requiring  implementation  of  a two-man  rule  the  combination  should  be  iterated  for  each 
set  of  roles. 


Anri  putt 


FMT  MSA.l  Management  of  security  attributes 

Hierarchical  to:  No  other  components. 

FMT  MSA.l.l  The  TSF  shall  enforce  the  [assignment:  access  control  SFP,  information 
flow  control  SFP]  to  restrict  the  ability  to  [selection:  changedefault,  query , modify , 
delete , [assignment:  other  operations]]  the  security  attributes  [assignment:  list  of 
security  attributes]  to  [assignment:  the  authorized  identified  roles]. 

Dependencies:  [FDP  ACC.l  Subset  access  control  or 
FDPIFC.l  Subset  information  flow  control) 

FMT  SMF.l  Specification  of  management  functions 
FMT  SMR.l  Security  roles 


FDP  IFC.l  Subset  information  flow  control 

Hierarchical  to:  No  other  components. 
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FDP  IFC.1.1  The  TSF  shall  enforce  the  (assignment:  information  flow  control  SFP]  on 
(assignment:  list  of  subjects,  information , and  operations  that  cause  controlled 
information  to  flow  to  and  from  controlled  subjects  covered  by  the  SFP\. 
Dependencies:  FDPIFF.l  Simple  security  attributes 
FDPIFC.2  Complete  information  flow  control 
Hierarchical  to:  FDPIFC.l 

FDP  IFC.2.1  The  TSF  shall  enforce  the  [assignment:  information  flow  control  SFP]  on 
[assignment:  list  of  subjects  and  information]  and  all  operations  that  cause  that 
information  to  flow  to  and  from  subjects  covered  by  the  SFP. 

FDP  IFC.2.2  The  TSF  shall  ensure  that  all  operations  that  cause  any  information  in 
the  TSC  to  flow  to  and  from  any  subject  in  the  TSC  are  covered  by  an  information 
flow  control  SFP. 

Dependencies:  FDP  IFF.l  Simple  security  attributes 

FDP  IFF.l  Simple  security  attributes 

Hierarchical  to:  No  other  components. 

FDP  IFF.l.l  The  TSF  shall  enforce  the  (assignment:  information  flow  control  SFP\ 
based  on  the  following  types  of  subject  and  information  security  attributes: 
(assignment:  the  minimum  number  and  type  of  security  attributes ]. 

FDP  IFF.1.2  The  TSF  shall  permit  an  information  flow  between  a controlled  subject 
and  controlled  information  via  a controlled  operation  if  the  following  rules  hold: 
[assignment:  for  each  operation , the  security  attribute-based  relationship  that  must 
hold  between  subject  and  information  security  attributes (. 

FDP  IFF.1.3  The  TSF  shall  enforce  the  [assignment:  additional  information  flow 
control  SFP  rules]. 

FDP  IFF.1.4  The  TSF  shall  provide  the  following  (assignment:  list  of  additional  SFP 
capabilities ]. 

FDP  IFF.1.5  The  TSF  shall  explicitly  authorize  an  information  flow  based  on  the 
following  rules:  [assignment:  rules,  based  on  security  attributes , that  explicitly 
authorize  information  flows]. 

FDP  IFF.1.6  The  TSF  shall  explicitly  deny  an  information  flow  based  on  the  following 
rules:  [assignment:  rules , based  on  security  attributes , that  explicitly  deny  information 
flows]. 

Dependencies:  FDP  IFC.l  Subset  information  flow  control 
FMT  MSA.3  Static  attribute  initialization 


FAU  GEN.l  Audit  data  generation 

Hierarchical  to:  No  other  components. 

FAU  GEN. l.l  The  TSF  shall  be  able  to  generate  an  audit  record  of  the  following 
auditable  events: 
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a)  Start-up  and  shutdown  of  the  audit  functions; 

b)  All  auditable  events  for  the  [selection:  minimum,  basic,  detailed,  not  specified] 
level  of  audit;  and 

c)  [assignment:  other  specifically  defined  auditable  events]. 

FAU  GEN. 1.2  The  TSF  shall  record  within  each  audit  record  at  least  the  following 
information: 

a)  Date  and  time  of  the  event,  type  of  event,  subject  identity,  and  the  outcome 
(success  or  failure)  of  the  event;  and 

b)  For  each  audit  event  type,  based  on  the  auditable  event  definitions  of  the 
functional  components  included  in  the  PP/ST,  [assignment:  other  audit  relevant 
information] 

Dependencies:  FPTSTM.l  Reliable  time  stamps 

FAU  GEN.2  User  identity  association 

Hierarchical  to:  No  other  components. 

FAU  GEN.2.1  The  TSF  shall  be  able  to  associate  each  auditable  event  with  the 
identity  of  the  user  that  caused  the  event. 

Dependencies:  FAUGEN.l  Audit  data  generation 
FIAUID.l  Timing  of  identification 

FMT  MTD.l  Management  of  TSF  data 

Hierarchical  to:  No  other  components. 

FMT  MTD.l.l  The  TSF  shall  restrict  the  ability  to  [selection:  change  default,  query , 
modify,  delete,  clear , [assignment:  other  operations]]  the  [assignment:  list  of  TSF 
data]  to  [assignment:  the  authorized  identified  roles]. 

Dependencies:  FMT  SMF.l  Specification  of  management  functions 
FMT_SMR.l  Security  roles 

FAUSEL.l  Selective  audit 

Hierarchical  to:  No  other  components. 

FAU  SEL.l.l  The  TSF  shall  be  able  to  include  or  exclude  auditable  events  from  the 
set  of  audited  events  based  on  the  following  attributes: 

a)  [selection:  object  identity,  user  identity,  subject  identity,  host  identity,  event  type] 

b)  [assignment:  list  of  additional  attributes  that  audit  selectivity  is  based  upon]. 
Dependencies:  FAU  GEN.l  Audit  data  generation 

FMT  MTD.l  Management  of  TSF  data 


FAU  ARP.l  Security  alarms 

Hierarchical  to:  No  other  components. 
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FAU  ARP.l.l  The  TSF  shall  take  (assignment:  list  of  the  least  disruptive  actions  ] upon 
detection  of  a potential  security  violation. 

Dependencies:  FAUSAA.l  Potential  violation  analysis 

FAUSAA.l  Potential  violation  analysis 

Hierarchical  to:  No  other  components. 

FAU  S A A.  l.l  The  TSF  shall  be  able  to  apply  a set  of  rules  in  monitoring  the  audited 
events  and  based  upon  these  rules  indicate  a potential  violation  of  the  TSP. 

FAU  S A A.  1.2  The  TSF  shall  enforce  the  following  rules  for  monitoring  audited 
events: 

a)  Accumulation  or  combination  of  [assignment:  subset  of  defined  auditable  events | 
known  to  indicate  a potential  security  violation; 

b)  [assignment:  any  other  rules]. 

Dependencies:  FAUGEN.l  Audit  data  generation 

FAUSAA.2  Profile  based  anomaly  detection 

Hierarchical  to:  FAU  SAA.l 

FAU  SAA.2.1  The  TSF  shall  be  able  to  maintain  profiles  of  system  usage,  where  an 
individual  profile  represents  the  historical  patterns  of  usage  performed  by  the 
member(s)  of  [assignment:  the  profile  target  group], 

FAU  SAA.2.2  The  TSF  shall  be  able  to  maintain  a suspicion  rating  associated  with 
each  user  whose  activity  is  recorded  in  a profile,  where  the  suspicion  rating 
represents  the  degree  to  which  the  user’s  current  activity  is  found  inconsistent  with 
the  established  patterns  of  usage  represented  in  the  profile. 

FAU  SAA.2.3  The  TSF  shall  be  able  to  indicate  an  imminent  violation  of  the  TSP 
when  a user’s  suspicion  rating  exceeds  the  following  threshold  conditions 
[assignment:  conditions  under  which  anomalous  activity  is  reported  by  the  TSF], 
Dependencies:  FIAUID.l  Timing  of  identification 

FAU  SAA.3  Simple  attack  heuristics 

Hierarchical  to:  FAU_SAA.l 

FAU  SAA.3.1  The  TSF  shall  be  able  to  maintain  an  internal  representation  of  the 
following  signature  events  [assignment:  a subset  of  system  events]  that  may  indicate  a 
violation  of  the  TSP. 

FAU  SAA.3.2  The  TSF  shall  be  able  to  compare  the  signature  events  against  the 
record  of  system  activity  discernible  from  an  examination  of  [assignment:  the 
information  to  be  used  to  determine  system  activity], 

FAU  SAA.3.3  The  TSF  shall  be  able  to  indicate  an  imminent  violation  of  the  TSP 
when  a system  event  is  found  to  match  a signature  event  that  indicates  a potential 
violation  of  the  TSP. 

Dependencies:  No  dependencies 
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FAUSAA.4  Complex  attack  heuristics 

Hierarchical  to:  FAU  SAA.3 

FAU  SAA.4.1  The  TSF  shall  be  able  to  maintain  an  internal  representation  of  the  following 
event  sequences  of  known  intrusion  scenarios  [assignment:  list  of  sequences  of 
system  events  whose  occurrence  are  representative  of  known  penetration  scenarios \ 

and  the  following  signature  events  [assignment:  a subset  of  system  events]  that  may 
indicate  a potential  violation  of  the  TSP. 

FAU  SAA.4.2  The  TSF  shall  be  able  to  compare  the  signature  events  and  event  sequences 
against  the  record  of  system  activity  discernible  from  an  examination  of  [assignment:  the 
information  to  be  used  to  determine  system  activity ’]. 

FAU  SAA.4.3  The  TSF  shall  be  able  to  indicate  an  imminent  violation  of  the  TSP  when 
system  activity  is  found  to  match  a signature  event  or  event  sequence  that  indicates  a 
potential  violation  of  the  TSP. 

Dependencies:  No  dependencies 


FAUSTG.l  Protected  audit  trail  storage 

Hierarchical  to:  No  other  components. 

FAU  STG.1.1  The  TSF  shall  protect  the  stored  audit  records  from  unauthorised 
deletion. 

FAU  STG.1.2  The  TSF  shall  be  able  to  [selection:  prevent , detect \ modifications  to  the 
audit  records. 

Dependencies:  FAUGEN.l  Audit  data  generation 

FAU  STG.2  Guarantees  of  audit  data  availability 

Hierarchical  to:  FAU_STG.l 

FAU  STG.2.1  The  TSF  shall  protect  the  stored  audit  records  from  unauthorized  deletion. 
FAU  STG.2.2  The  TSF  shall  be  able  to  [selection:  prevent,  detect]  modifications  to  the 
audit  records. 

FAU  STG.2.3  The  TSF  shall  ensure  that  [assignment:  metric  for  saving  audit  records J 
audit  records  will  be  maintained  when  the  following  conditions  occur:  [selection: 
audit  storage  exhaustion,  failure,  attack ]. 

Dependencies:  FAU  GEN.l  Audit  data  generation 

FAU  STG.3  Action  in  case  of  possible  audit  data  loss 

Hierarchical  to:  No  other  components. 

FAU  STG.3.1  The  TSF  shall  take  [assignment:  actions  to  be  taken  in  case  of  possible 
audit  storage  failure]  if  the  audit  trail  exceeds  [assignment:  pre-defined  limit]. 

Dependencies:  FAU_STG.l  Protected  audit  trail  storage 


System  Protection  Profile  - Industrial  Control  Systems 
Version  1 .0 


Page  52  of  1 5 1 


National  Institute  of  Standards  & Technology 
System  Protection  Profile  - Industrial  Control  Systems 


NET 

National  SmlStuf*  at 
Standards  and  Technology 


FAUSTG.4  Prevention  of  audit  data  loss 

Hierarchical  to:  FAUSTG.3 

FAU  STG.4.1  The  TSF  shall  [selection:  ‘ignore  auditable  events’,  ’prevent  auditable 
events,  except  those  taken  by  the  authorized  user  with  special  rights  ’,  ‘ overwrite  the 
oldest  stored  audit  records  ’]  and  [assignment:  other  actions  to  be  taken  in  case  of  audit 
storage  failure ] if  the  audit  trail  is  full. 

Dependencies:  FAUSTG.l  Protected  audit  trail  storage 


FAUSAR.l  Audit  review 

120  This  component  will  provide  authorized  users  the  capability  to  obtain  and  interpret  the 
information.  In  case  of  human  users  this  information  needs  to  be  in  a human 
understandable  presentation.  In  case  of  external  IT  entities  the  information  needs  to  be 
unambiguously  represented  in  an  electronic  fashion. 

Hierarchical  to:  No  other  components. 

FAU  SAR.l.l  The  TSF  shall  provide  [assignment:  authorized  users]  with  the 
capability  to  read  [assignment:  list  of  audit  information [ from  the  audit  records. 

FAU  SAR.1.2  The  TSF  shall  provide  the  audit  records  in  a manner  suitable  for  the 
user  to  interpret  the  information. 

Dependencies:  FAU  GEN.l  Audit  data  generation 

FAU  SAR.2  Restricted  audit  review 

Hierarchical  to:  No  other  components. 

FAU  SAR.2.1  The  TSF  shall  prohibit  all  users  read  access  to  the  audit  records,  except 
those  users  that  have  been  granted  explicit  read-access. 

Dependencies:  FAU_SAR.l  Audit  review 

FAU  SAR.3  Selectable  audit  review 

Hierarchical  to:  No  other  components. 

FAU  SAR.3.1  The  TSF  shall  provide  the  ability  to  perform  [selection:  searches, 
sorting,  ordering ] of  audit  data  based  on  [assignment:  criteria  with  logical  relations]. 
Dependencies:  FAU_SAR.l  Audit  review 


6,1.14  TOE  Integrity 

FPT  PHP.l  Passive  detection  of  physical  attack 

Hierarchical  to:  No  other  components. 

FPT  PHP.l.l  The  TSF  shall  provide  unambiguous  detection  of  physical  tampering 
that  might  compromise  the  TSF. 
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FPT  PHP.1.2  The  TSF  shall  provide  the  capability  to  determine  whether  physical 
tampering  with  the  TSF’s  devices  or  TSF’s  elements  has  occurred. 

Dependencies:  FMTMOF.l  Management  of  security  functions  behavior 

FPT  PHP.2  Notification  of  physical  attack 

Hierarchical  to:  FPT  PHP.l 

FPT  PHP.2.1  The  TSF  shall  provide  unambiguous  detection  of  physical  tampering  that 
might  compromise  the  TSF. 

FPT  PHP.2.2  The  TSF  shall  provide  the  capability  to  determine  whether  physical 
tampering  with  the  TSF’s  devices  or  TSF’s  elements  has  occurred. 

FPT  PHP.2.3  For  [assignment:  list  of  TSF  devices/elements  for  which  active  detection  is 
required ],  the  TSF  shall  monitor  the  devices  and  elements  and  notify  [assignment:  a 
designated  user  or  role ] when  physical  tampering  with  the  TSF’s  devices  or  TSF’s 
elements  has  occurred. 

Dependencies:  FMTMOF.l  Management  of  security  functions  behavior 

FPT  PHP.3  Resistance  to  physical  attack 

Hierarchical  to:  No  other  components. 

FPT  PHP.3.1  The  TSF  shall  resist  [assignment:  physical  tampering  scenarios]  to  the 
[assignment:  list  of  TSF  devices/elements]  by  responding  automatically  such  that  the 
TSP  is  not  violated. 

Dependencies:  No  dependencies 
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FDP  DAU.2  Data  authentication  with  identity  of  guarantor 

Hierarchical  to:  FDP_DAU.l 

FDP  DAU.2.1  The  TSF  shall  provide  a capability  to  generate  evidence  that  can  be  used  as 
a guarantee  of  the  validity  of  [assignment:  list  of  objects  or  information  types]. 
FDPDAU.2.2  The  TSF  shall  provide  [assignment:  list  of  subjects]  with  the  ability  to  verify 
evidence  of  the  validity  of  the  indicated  information  and  the  identity  of  the  user  that 
generated  the  evidence. 

Dependencies:  FIA  UID.l  Timing  of  identification 


FDP  UIT.l  Data  exchange  integrity 

Hierarchical  to:  No  other  components. 

FDP  UIT.l.l  The  TSF  shall  enforce  the  [assignment:  access  control  SFP(s)  and/or 
information  flow  control  SFP(s)]  to  be  able  to  [selection:  transmit , receive  [ user  data 
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in  a manner  protected  from  [selection:  modification , deletion , insertion , replay ] 
errors. 

Dependencies:  [FDPACC.l  Subset  access  control,  or 
FDPIFC.l  Subset  information  flow  control] 

[FTPITC.l  Inter-TSF  trusted  channel,  or 
FTPTRP.l  Trusted  path] 
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FPT  STM.1.1  The  TSF  shall  be  able  to  provide  reliable  time  stamps  for  its  own  use. 

Dependencies:  No  dependencies 

FDP  ACF.l  Security  attribute  based  access  control 

Hierarchical  to:  No  other  components. 

FDP  ACF.l.l  The  TSF  shall  enforce  the  [assignment:  access  control SFP]  to  objects 
based  on  [assignment:  security  attributes , named  groups  of  security  attributes ]. 
Dependencies:  FDP  ACC.l  Subset  access  control 
FMTMSA.3  Static  attribute  initialization 

FMTMSA.l  Management  of  security  attributes 

Hierarchical  to:  No  other  components. 

FMT  MSA.1.1  The  TSF  shall  enforce  the  [assignment:  access  control  SFP,  information 
flow  control  SFP ] to  restrict  the  ability  to  [selection:  change  default,  query , modify, 
delete,  [assignment:  other  operations]]  the  security  attributes  [assignment:  list  of 
security  attributes]  to  [assignment:  the  authorized  identified  roles]. 

Dependencies:  [FDP  ACC.l  Subset  access  control  or 
FDP  IFC.l  Subset  information  flow  control] 

FMT  SMF.l  Specification  of  management  functions 
FMT  SMR.l  Security  roles 

FMT  MSA.3  Static  attribute  initialization 

Hierarchical  to:  No  other  components. 

FMT  MSA.3.1  The  TSF  shall  enforce  the  [assignment:  access  control  SFP,  information 
flow  control  SFP]  to  provide  [selection:  restrictive,  permissive,  other  property]  default 
values  for  security  attributes  that  are  used  to  enforce  the  SFP. 

FMT  MSA.3.2  The  TSF  shall  allow  the  [assignment:  the  authorized  identified  roles]  to 
specify  alternative  initial  values  to  override  the  default  values  when  an  object  or 
information  is  created. 

Dependencies:  FMT  MSA.l  Management  of  security  attributes 
FMT  SMR.l  Security  roles 
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FDPIFC.l  Subset  information  flow  control 

Hierarchical  to:  No  other  components. 

FDP  IFC.l.l  The  TSF  shall  enforce  the  [assignment:  information  flow  control  SFP]  on 
[assignment:  list  of  subjects,  information , and  operations  that  cause  controlled 
information  to  flow  to  and  from  controlled  subjects  covered  by  the  SFP\. 
Dependencies:  FDPIFF.l  Simple  security  attributes 

FMTJVlOF.l  Management  of  security  functions  behavior 

Hierarchical  to:  No  other  components. 

FMT  MOF.1.1  The  TSF  shall  restrict  the  ability  to  [selection:  determine  the  behavior 
of  disable , enable , modify  the  behavior  of\  the  functions  [assignment:  list  of 
functions \ to  [assignment:  the  authorized  identified  roles]. 

Dependencies:  FMT  SMF.l  Specification  of  management  functions 
FMTSMR.l  Security  roles 

6.1.18  Secure  Communications  Channels 

FPTITA.l  Inter-TSF  availability  within  a defined  availability  metric 

Hierarchical  to:  No  other  components. 

FPTITA.1.1  The  TSF  shall  ensure  the  availability  of  [assignment:  list  types  of  TSF 
data [ provided  to  a remote  trusted  product  within  [assignment:  a defined  availability 
metric \ given  the  following  conditions  [assignment:  conditions  to  ensure  availability [. 
Dependencies:  No  dependencies 

FPT  ITC.1  Inter-TSF  confidentiality  during  transition 

Hierarchical  to:  No  other  components. 

The  TSF  shall  protect  all  data  transmitted  from  the  TSF  to  a remote  trusted 
product  from  unauthorized  disclosure  during  transmission. 

Dependencies:  No  dependencies 

FPT  ITI.l  Inter-TSF  detection  of  modification 

Hierarchical  to:  No  other  components. 

FPTITI.1.1  The  TSF  shall  provide  the  capability  to  detect  modification  of  all  TSF 
data  during  transmission  between  the  TSF  and  a remote  trusted  product  within  the 
following  metric:  [assignment:  a defined  modification  metric |. 

FPT  ITI.1.2  The  TSF  shall  provide  the  capability  to  verify  the  integrity  of  all  TSF 
data  transmitted  between  the  TSF  and  a remote  trusted  product  and  perform 
[assignment:  action  to  be  taken [ if  modifications  are  detected. 

Dependencies:  No  dependencies. 

FPT  ITI.2  Inter-TSF  detection  and  correction  of  modification 

Hierarchical  to:  FPT  ITI.l 
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FPTITI.2.3  The  TSF  shall  provide  the  capability  to  correct  [assignment:  type  of 
modification ] of  all  TSF  data  transmitted  between  the  TSF  and  a remote  trusted 
product. 

Dependencies:  No  dependencies. 

FPT  RCV.5  Continuous  secure  degraded  operations 

Hierarchical  to:  No  other  components. 

FPT  RCV.5.1  The  TSF  shall  ensure  that  [assignment:  security  controls  and  list  of 
failures/service  discontinuities ] that  continuous  degraded  operations  can  occur  in  a 
secure  state. 

FPT  RCV.5.2  The  functions  provided  by  the  TSF  to  support  continuous  but 
degraded  operations  in  event  of  failure/service  discontinuities  shall  be  configurable 
to  support  [assignment:  prioritized  operations  and  configurations ]. 

FPTRCV.5.3  The  TSF  shall  ensure  that  the  transition  for  recovery  from  degraded 
to  normal  operations  [assignment:  list  of  security  controls  and  configurations J can  be 
performed  in  an  orderly,  consistent  and  secure  state. 

FPTSEP.l  TSF  domain  separation 

Hierarchical  to:  No  other  components. 

FPT  SEP.1.1  The  TSF  shall  maintain  a security  domain  for  its  execution  that 
protects  it  from  interference  and  tampering  from  untrusted  objects. 

FPT  SEP.1.2  The  TSF  shall  enforce  separation  between  the  security  domains  of 
subjects  in  the  TSC. 

Dependencies:  No  dependencies. 

FPT  SSP.l  Simple  trusted  acknowledgement 

Hierarchical  to:  No  other  components. 

FPT  SSP.1.1  The  TSF  shall  acknowledge,  when  requested  by  another  part  of  the 
TSF,  the  receipt  of  an  unmodified  TSF  data  transmission. 

Dependencies:  FPT1TT.1  Basic  internal  TSF  data  transfer  protection 
FTP  SSP.2  Mutual  trusted  acknowledgement 

Hierarchical  to:  FPT_SSP.l 

FTP  SSP.2.2  The  TSF  shall  ensure  that  the  relevant  parts  of  the  TSF  know  the 
correct  status  of  transmitted  data  among  its  different  parts,  using 
acknowledgements. 

Dependencies:  FPT  ITT.  1 Basic  internal  data  transfer  protection. 

FPT  STM.l  Reliable  time  stamps 

Hierarchical  to:  No  other  components. 

The  TSF  shall  be  able  to  provide  reliable  time  stamps  for  the  systems  use. 

Dependencies:  No  dependencies. 
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FPTTDC.l  Inter-TSF  basic  data  consistency 

Hierarchical  to:  No  other  components. 

FPTTDC.1.1  The  TSF  shall  provide  the  capability  to  consistently  interpret 
(assignment:  list  of  TSF  data  types J when  shared  between  the  TSF  and  another 
trusted  product. 

FPTTDC.1.2  The  TSF  shall  use  (assignment:  list  of  interpretation  rules  to  be  applied 
by  the  TSF\  when  interpreting  the  TSF  data  from  another  trusted  IT  product. 

Dependencies:  No  dependencies. 

FTP  ITC.l  Inter-TSF  trusted  channel 

Hierarchical  to:  No  other  components. 

FTP  ITC.1.1  The  TSF  shall  provide  a communication  channel  between  itself  and  a 
remote  trusted  product  that  is  logically  distinct  from  other  communication  channels 
and  provides  assured  identification  of  its  end  points  and  protection  of  the  channel 
data  from  modification  or  disclosure. 

FTPITC.1.2  The  TSF  shall  permit  [selection:  the  TSF,  the  remote  trusted  product] 
to  initiate  communication  via  the  trusted  channel. 

FPTITC.1.3  The  TSF  shall  initiate  communication  via  trusted  channel  for 
[assignment:  list  of functions  for  which  a trusted  channel  is  required]. 

Dependencies:  No  dependencies. 

FTP  TRP.l  Trusted  path 

Hierarchical  to:  No  other  components. 

FTP  TRP.1.1  The  TSF  shall  provide  a communication  path  between  itself  and 
[selection:  remote,  local]  users  that  is  logically  distinct  from  other  communications 
paths  and  provides  assured  identification  of  its  end  points  and  protection  of  the 
communicated  data  from  modification  or  disclosure. 

FPT  TRP.1.2  The  TSF  shall  permit  [selection:  the  TSF,  local  users,  remote  users]  to 
initiate  communications  via  the  trusted  path. 

FPTTRP.1.3  The  TSF  shall  require  the  use  of  the  trusted  path  for  [selection:  initial 
user  authentication,  [assignment:  other  services  for  which  trusted  path  is  required]]. 

Dependencies:  No  dependencies. 

FDPETC.l  Export  of  user  data  without  security  attributes 

Hierarchical  to:  No  other  components. 

FDP  ETC.  1.1  The  TSF  shall  enforce  the  [assignment:  access  control SFP(s)  and/or 
information  flow  control  SFP(s)]  when  exporting  user  data,  controlled  under  the 
SFP(s),  outside  the  TSC. 

FDP  ETC.1.2  The  TSF  shall  export  the  user  data  without  the  user  data’s  associated 
security  attributes. 
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6.1.19  Management  Functions 

FMT  SMF.l  Specification  of  Management  Functions 

Hierarchical  to:  No  other  components. 

FMT  SMF.1.1  The  TSF  shall  be  capable  of  performing  the  following  security 
management  functions:  [assignment:  list  of  security  management  functions  to  be 
provided  by  the  TSFj. 

Dependencies:  No  Dependencies. 

FMT  MOF.2  Security  policy  and  security  function  mapping 

Hierarchical  to:  No  other  components. 

FMT  MOF.2.1  The  TSF  shall  be  capable  of  performing  the  following  security 
management 

functions:  [assignment:  list  of  security  management  functions  to  be  provided  by 
the  TSFJ. 

Dependencies:  No  Dependencies 

<Editor’s  Note:  The  remaining  management  functions  are  extensions  to  ISO  15408,  that 
is,  they  are  not  found  in  the  ISO  standard> 

FMT  MTD.4  Management  of  TSF  data  to  policy  mapping 

Hierarchical  to:  No  other  components. 

FMT  MTD.4.1  The  TSF  shall  restrict  the  ability  to  specify  the  mapping  for 
[assignment:  list  of  security  management  functions  provided  by  the  TSF],  and 
[assignment:  list  of  system  security  policies ]. 

FMT  MTD.4.2  The  TSF  shall  distinguish  between  [assignment:  system  domains ], 
[assignment:  security  policy  governing  domain],  and  [assignment:  data  and  its 
distribution  and  management]. 

Dependencies:  FMT_MTD.1  Management  of  TSF  data 


FMT  REV.  1 Access  revocation 

Physical  and  IT  access  shall  be  revoked  within  [assignment:  time  span ] for  personnel 
whose  employment  or  contractual  relationship  is  terminated  or  for  personnel  who  are 
temporarily  not  actively  involved  in  process  control  and  operations  (for  example,  workers 
on  strike,  workers  on  a leave  of  absence,  etc.) 

FCS  CKM.l  Cryptographic  key  generation 

Hierarchical  to:  No  other  components. 

FCS  CKM.1.1  The  TSF  shall  generate  cryptographic  keys  in  accordance  with  a 
specified  cryptographic  key  generation  algorithm  [assignment:  cryptographic  key 
generation  algorithm]  and  specified  cryptographic  key  sizes  [assignment: 
cryptographic  key  sizes]  that  meet  the  following:  [assignment:  list  of  standards]. 
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Dependencies:  [FCSCKM.2  Cryptographic  key  distribution 
or 

FCSCOP.l  Cryptographic  operation] 

FCSCKM.4  Cryptographic  key  destruction 
FMTMSA.2  Secure  security  attributes 

FCS  CKM.2  Cryptographic  key  distribution 

Hierarchical  to:  No  other  components. 

FCSCKM.2.1  The  TSF  shall  distribute  cryptographic  keys  in  accordance  with  a 
specified  cryptographic  key  distribution  method  [assignment:  cryptographic  key 
distribution  method]  that  meets  the  following:  [assignment:  list  of  standards]. 
Dependencies:  [FDPITC.l  Import  of  user  data  without  security  attributes 
or 

FCSCKM.l  Cryptographic  key  generation! 

FCS  CKM.4  Cryptographic  key  destruction 
FMT  MSA.2  Secure  security  attributes 

FCSCKM.3.1  Cryptographic  key  access 

Hierarchical  to:  No  other  components 

FCSCKM.3.1  The  TSF  shall  perform  [assignment:  type  of  cryptographic  key  access] 
in  accordance  with  a specified  cryptographic  key  access  method  [assignment: 
cryptographic  key  access  method]  that  meets  the  following:  [assignment:  list  of 
standards]. 

Dependencies:  [FDP  ITC.l  Import  of  user  data  without  security  attributes 
or 

FCS  CKM.l  Cryptographic  key  generation) 

FCS  CKM.4  Cryptographic  key  destruction 
FMT  MSA.2  Secure  security  attributes 

FCS  CKM.4  Cryptographic  key  destruction 

Hierarchical  to:  No  other  components. 

FCS  CKM.4.1  The  TSF  shall  destroy  cryptographic  keys  in  accordance  with  a 
specified  cryptographic  key  destruction  method  [assignment:  cryptographic  key 
destruction  method]  that  meets  the  following:  [assignment:  list  of  standards]. 
Dependencies:  [FDP  ITC.l  Import  of  user  data  without  security  attributes 
or 

FCS  CKM.l  Cryptographic  key  generation) 

FMT  MSA.2  Secure  security  attributes 

FCS  COP.l  Cryptographic  operation 

Hierarchical  to:  No  other  componenets. 

FCSCOP.1.1  The  TSF  shall  perform  [assignment:  list  of  cryptographic  operations] 
in  accordance  with  a specified  cryptographic  algorithm  [assignment:  cryptographic 
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algorithm ] and  cryptographic  key  sizes  [assignment:  cryptographic  key  sizes]  that 
meet  the  following:  [assignment://^  of  standards]. 

Dependencies:  [FDP  ITC.l  Import  of  user  data  without  security  attributes 
or 

FCS  CKM.l  Cryptographic  key  generation! 

FCS  CKM.4  Cryptographic  key  destruction 
FMT  MSA.2  Secure  security  attributes 


FPTPHP.5  Backup  and  Restore 

The  TSF  shall  include  the  capability  to  backup  and  restore  the  system  configuration 
including  critical  programs,  controller  instructions  and  parameters,  and  instructions  and 
parameters  for  all  sensors  and  actuators.  Backups  shall  be  performed  [assignment: 
frequency]  and  whenever  critical  operating  parameters  [assignment:  identify  the  critical 
operating  parameters]  are  changed. 


FPT  PHP.5  Backup  and  Restore  Self-Testing 

The  TSF  backup  and  restore  procedure  shall  be  able  to  be  self-tested  during  regular 
operations  and  planned  maintenance.  Self-Test  to  be  evoked  as  part  of  FPT  TST.  1 . 


Security 


'‘emeriti 


< Edit  or ’s  Note:  These  requirements  are  extensions  to  ISO  15408,  that  is,  they  are  not 
found  in  the  ISO  standard  > 

PHY  SOB.2  Strength  of  Boundary  Access  Control 

The  TSF  shall  provide  physical  access  control  to  critical  ICS  components  including,  but 
not  limited  to:  control  room(s),  servers,  controller,  sensors,  actuators,  and  the  physical 
plant  under  control. 

<Editor  s Note:  This  requirement  is  included  as  an  example.  Physical  security 
requirements  should  he  inserted  in  this  section  as  appropriate  to  the  speci  fic  nature  of  the 
target  ICS  > 


6.1,21  Security  Event  Monitoring 

<Editor 's  Note:  These  requirements  are  extensions  to  ISO  15408,  that  is,  they  are  not 
found  in  the  ISO  standard  > 

FEMEDI.l  Event  Definition  and  Identification 
Hierarchical  to:  No  other  components. 


System  Protection  Profile  - Industrial  Control  Systems 
Version  1.0 


Page  61  of  151 


National  Institute  of  Standards  & Technology 
System  Protection  Profde  - Industrial  Control  Systems 


iviicsrir 

National  «t 

Storvdcrsjts.  anti  "teclwatagy 


FEMEDI.1.1  the  TSF  shall  provide  automated  event  monitoring  for  [select:  event 
identification , name  of  interface , location, component  name  and  functions , 

[assignment:  other  event  information J. 

FEMEDI.1.2  The  TSF  shall  provide  the  ability  to  [assignment:  alarm  parameter 
settings , pre-defined  security  values]. 

FEMEDI.1.3  The  TSF  shall  prescribe  the  information  flow  for  each  event 
[assignment:  monitored  interface/component,  monitoring  device , information  flow 
from  receipt  of  alarm  to  its  transmittal  to  end  receiver  for  action | and  categorization  of 
the  alarm  to  the  system  TSF  [assignment:  category  and  impact  of  alarm j. 
Dependencies:  FMT_SMF.l  Specification  of  management  functions 
FMT  SMR.l  Security  roles 

FPTPHP.  FPTPHP.4  Domain  definition  and  response  to  alarm 


FEMEDI.2  Interaction  of  system  event  monitoring  components 
Hierarchical  to:  FEMEDI.l  Event  definition  and  identification 
FEM  EDI.2.1 

defines  the  iinteractions  of  technical  and  operational  and  management  security 
controls  components  that  support  event  monitoring  associated  with  the  system 
environment.  Also  defines  the  system  environment  security  controls  event 
monitoring  reporting  mechanism  from  either  direct  or  indirect  interface  with  the 
System  technical  security  controls  components  that  support  event  monitoring.  May 
be  used  in  conjunction  with  FPT  PHP. 

FEMEDI.3  Alarm  audit  requirements  define  the  audit  requirements  for  the 
defined  alarms. 

FEM  EDI.4  Alarm  response  identifies  that  the  alarm  response  to  authorized  pre- 
defined security  event  monitoring  alarms  be  obtained  and  documented;  identifies 
the  roles  and  responsibilities  that  are  defined  for  receipt  of  alarm  and  required 
action,  including  any  timing  constraints  (possible  roles  are  specified  in 
FMTSMR.l);  defines  security  event  alarm  reporting  procedures  and  mechanisms 
for  the  exchange  of  security  event  alarm  information  between  the  System  IT  and 
System  environment  security  controls;  and  specifies  that  event  alarm  audit  data  be 
transformed  to  a specific  format  to  support  real-time  analysis,  and  into  a different 
useful  format  for  delivery  to  authorised  users  for  review  (see  application  notes  for 
FAUSAA) 

FPT  STM.l  Reliable  time  stamps 

Hierarchical  to:  No  other  components. 

The  TSF  shall  be  able  to  provide  reliable  time  stamps  for  the  systems  use. 

Dependencies:  No  dependencies. 
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6.1,22  Requirements  for  interfaces  between  sys 


components 


<Editor  ’s  Note:  These  requirements  are  extensions  to  ISO  15408,  that  is,  they  are  not 
found  in  the  ISO  standard.  > 


FPT  PHP.2  Authentication  Integration 

The  TSF  shall  integrate  authentication  of  user  access  with  authentication  for  physical 
access  such  that  user  access  is  not  granted  for  a user  not  identified  by  the  physical  access 
control  as  being  physically  present  and  such  that  user  access  is  locked  when  the  physical 
access  control  indicates  that  the  user  is  no  longer  physically  present. 


for  compos; 


lity  and  interopera biiitv  be 


co  mi 


16  fits 


FPT  PHP.4  Domain  Definition  and  Response  to  Alarm 

The  TSF  shall  identify  and  define  the  domains,  which  comprise  the  system,  the  physical 
boundary  for  each  domain,  and  the  security  policy(s),  which  governs  each  of  the 
domains.  The  system  security  alarms  may  be  tailored  for  the  components  being  governed 
by  the  specific  domain.  The  definition  for  each  alarm  shall  be  well  defined,  to  include 
the  alarm  threshold,  where  it  is  reported,  and  the  requisite  system  response. 


This  section  documents  any  requirements  specific  to  security  composability  that  have  not 


□lure  merits 


<Editor 's  Note:  These  requirements  are  extensions  to  ISO  15408,  that  is,  they  are  not 
found  in  the  ISO  standard.  > 

FCM_IDI.l  Configuration  Change  Requests  and  Actions 

The  STOE  shall  be  subject  to  configuration  management  with  an  explicit  change  control 
and  review  process. 

6.2  STOE  Security  Assurance  Requirements 

This  section  contains  the  assurance  requirements  for  the  TOE.  The  assurance 
requirements  are  listed  in  summary  form  in  Table  13  below,  with  more  detail  on  the 
assurance  requirements  following  the  Table.  The  general  intent  of  the  assurance 
requirements  and  associated  system  evaluation  activities  is  to  confirm  that  the  acceptable 
level  of  residual  risk  as  documented  in  the  SPP  is  achieved  in  the  operational  system 

The  baseline  evaluation  assurance  level  (EAL)  for  Industrial  Control  Systems  is  EAE  3+. 
The  "+"  indicates  that  the  EAL  is  as  defined  in  ISO  15408  Part  3 with  additional 
assurance  requirements.  In  this  case  the  additional  requirements  reflect  the  assurances 
associated  with  design,  development,  integration,  testing  and  deployment  of  a system  as 
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opposed  to  a component  or  product.  In  addition,  because  the  ICS  is  a system,  a 
combination  of  technical  and  operations  and  management  security  control  elements  must 
be  considered. 


<Editor  's  Note:  Table  13  and  the  text  below  it  outlines  extensions  to  the  assurance 
requirements  that  are  building  on  ISO  system  work  in  concert  with  NIST  work  on  security 
controls> 

Table  13  - STOE  Security  Assurance  Requirements 


. 

Component  Name 
1 


Class  ACM:  Configuration  management 


1 

ACM  CAP. 3 

Authorization  controls 

2 

ACM  SCP.l 

TOE  CM  Coverage 

3 

ACM  OBM.l 

CM  Operational  Baseline  and  Maintenance 

Class  ADO:  Delivery  and  Operation 

4 

ADO  DEL.l 

Delivery  procedures 

5 

ADO  IGS.l 

Installation,  generation  and  start-up 

6 

ADO  SIC.l 

Site  interoperability  check 

Class  AGD:  Guidance  documents 

7 

AGD  ADM.l 

Administrator  guidance 

8 

AGD  USR.l 

User  guidance 

9 

AGD  OCD.l  • 

System  operational  configuration  definition  guidance 

Class  ALC 

Life  cycle  support 

10 

ALC  DVS.l 

Identification  of  security  measures 

11 

ALC  FLR.3 

Systematic  flaw  remediation 

12 

ALC  OPS.l 

Operational  security 

Class  ASA 

Security  awareness 

- 

13 

ASA  PPG.2 

Verified  operational  security  guidance 

Class  ASC 

O&M  security 

14 

ASC  PPO.l 

Verified  policy  and  procedures 

15 

ASC  PFA.l 

Asset  records  confirmation 

16 

ASC  OIN.l 

Operational  integration 

Class  ASD 

System  Architecture 
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No. 

Component 

Component  Name 

17 

ASD  SAD.l 

Operational  system  architecture  design 

18 

ASD  IFS.l 

Operational  system  interface  functional  specification 

19 

ASD  SSD.2 

Subsystem  design 

20 

ASD  IMP.l 

Implementation  representation 

21 

ASD  COM.l 

System  security  concept  of  operations 

Class  ATE:  Tests 

7? 

ATE  COV.2 

Analysis  of  coverage 

23 

ATE  DPT.l 

Testing  high-level  design 

24 

ATE  FUN.l 

Functional  testing 

25 

ATE  IND.2 

Independent  testing-  sample 

26 

ATE  AST.3 

Operational  testing  policy  conformance 

Class  AVA:  Vulnerability  Assessment 

27 

AVA  SOFT 

Strength  of  STOE  security  function  evaluation 

28 

AVA  MSU.l 

Examination  of  guidance 

29 

AVA_VLA.l 

Developer  vulnerability  analysis 

Class  AMA:  Assurance  Maintenance 

30 

ASA_AMP.l 

Assurance  maintenance  plan 

31 

AMAEVD.l 

Evidence  of  assurance  maintenance 

32 

AMA_SIA.  1 

■ 

Security  impact  analysis 

1,2,1  Configuration  Managsmant  (AGRA) 

Authorization  Controls  (ACMCAP.3) 

Dependencies:  ALCDVS.l  Identification  of  security  measures 

ACM  CAP.3.1D  The  developer  shall  provide  a reference  for  the  TOE. 

ACM  CAP.3.2D  The  developer  shall  use  a CM  system. 

ACM  CAP.3.3D  The  developer  shall  provide  CM  documentation. 
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ACM  CAP.3.1C  The  reference  for  the  STOE  shall  be  unique  to  each  version  of  the  TOE. 


ACM  CAP.3.2C  The  STOE  shall  be  labeled  with  its  reference. 


ACMCAP.3.3C 

ACMCAP.3.4C 

ACMCAP.3.5C 

ACM  CAP.3.6C 
ACMCAP.3.7C 
ACMCAP.3.8C 

ACMCAP.3.9C 

ACMCAP.3.10C 

ACM  CAP.3.1E 


The  CM  documentation  shall  include  a configuration  list  and  a plan. 

The  configuration  list  shall  describe  the  configuration  items  that  comprise  the 
TOE. 

The  CM  documentation  shall  describe  the  method  used  to  uniquely  identify 
the  configuration  items. 

The  CM  system  shall  uniquely  identify  all  configuration  items. 

The  CM  Plan  shall  describe  how  the  CM  system  is  used. 

The  evidence  shall  demonstrate  that  the  CM  system  is  operating  in 
accordance  with  the  CM  Plan. 

The  CM  documentation  shall  provide  evidence  that  all  configuration  have 
been  and  are  being  effectively  maintained  under  the  CM  system. 

The  CM  system  shall  provide  measures  such  that  only  authorized  changes 
are  made  to  the  configuration  items. 

The  evaluator  shall  confirm  that  the  information  provided  meets  all  requirements 
for  content  and  presentation  of  evidence. 


STOE  CM  Coverage  (ACM  SCP.l) 

Dependencies:  ACC_CAP.3  Authorization  controls 


ACM  SCP.1.1D  The  developer  shall  provide  a list  of  configuration  items  for  the  TOE. 


ACM  SCP.1.1C 


The  list  of  configuration  items  shall  include  the  following: 
implementation  representation  and  the  evaluation  evidence  required 
by  the  assurance  components  in  the  ST. 


ACM  SCP.1.1E 


The  evaluator  shall  confirm  that  the  infonnation  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 
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Operational  Baseline  & Maintenance  (ACMOBM.l) 

Dependencies:  ACM  CAP. 3 Authorization  controls 

ACM  SCP.l  TOE  CM  coverage 

\CM  OBM  1 ID  The  developer/system  owner  shall  use  a CM  system  for  the 

initial/most  recent  evaluated  system,  which  shall  be  called  the 
“Baseline”. 


ACM  OBM.1.2D 


The  CM  system  shall  track  and  monitor  each  change,  proposed  and 
actual  to  the  system  Baseline,  and  its  evaluation  status. 


ACM  OBM.1.3D 


The  CM  system  shall  report  the  current  operational  system 
configuration  baseline. 


ACM  OBM.1.4D 


The  developer/system  owner  shall  provide  CM  documentation  of  the 
Baseline  system. 


ACM  OBM. 1. 1C 


The  CM  System  shall  uniquely  identify  the  System  TOE  Baseline,  each 
associated  change,  and  its  evaluation  status. 


ACM  OBM  1 2 C The  CM  Plan  shall  describe  how  the  system  baseline  is  maintained,  and 
~ changes  to  the  baseline  are  tracked  and  controlled. 


ACM  OBM.1.1E 


The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 


Deft verv  and  Operation  (ADO) 


Delivery  Procedures  (ADO  DEL.  1) 
Dependencies:  No  dependencies. 


ADO  DEL.1.1D 

ADO  DEL.1.2D 
ADO  DEL.1.1C 


The  developer  shall  document  procedures  for  delivery  of  the  System 
TOE  or  parts  of  it  to  the  user. 

The  developer  shall  use  the  delivery  procedures 

The  delivery  documentation  shall  describe  all  procedures  that  are 
necessary  to  maintain  security  when  distributing  versions  of  the  System 
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TOE  to  a user’s  site. 


ADO  DEL. 1.1E 


The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 


Installation,  Generation  and  Start-up  Procedures  (ADOIGS.l) 


Dependencies:  No  dependencies. 


ADO  IGS.1.1D 


The  developer  shall  document  procedures  necessary  for  the  secure 
installation,  generation,  and  start-up  of  the  System  TOE. 


ADO  IGS.1.1C 


The  installation,  generation  and  start-up  documentation  shall 
describe  the  steps  necessary  for  secure  installation,  generation,  and 
start-up  of  the  System  TOE 


ADO  IGS.1.1E 


The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 


ADO  IGS.1.2E 


The  evaluator  shall  determine  that  the  installation,  generation,  and  start-up 
procedures  result  in  a secure  configuration. 


Site  Interoperability  Check  (ADO  SIC.l) 


Dependencies:  No  dependencies. 


ADO  SIC.1.1D 


The  developer  shall  document  procedures  necessary  to  ensure  that 
components  and  interfaces  that  comprise  the  System  TOE,  especially 
those  to  legacy  security  controls  and  interfaces  can  be  started  up  and 
interoperate  in  a secure  manner. 


ADO  S1C.1.1C 


The  site  interoperability  check  procedures  documentation  shall 
describe  the  steps  necessary  for  verification  of  secure  start-up  and 
interoperation  of  the  System  TOE  in  its  environment 


ADO  SIC. 1.1E 


The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 


ADO  SIC.1.2E 


The  evaluator  shall  determine  that  the  start-up  and  interoperability  check 
procedures  result  in  a secure  configuration. 
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Administrator  Guidance  (AGDADM.l) 


Dependencies: 


ASD  SAD.  1 Operational  System  Architecture  Design 


AGD  ADM.  1. ID 


The  developer  shall  provide  administrator  guidance  addressed  to 
system  administrative  personnel. 


AGD  ADM. 1. 1C 


The  administrator  guidance  shall  describe  the  administrative 
functions  and  interfaces  available  to  the  administrator  of  the  System 


TOE. 


AGD  ADM.1.2C  The  administrator  guidance  shall  describe  how  to  administer 
the  System  TOE  in  a secure  manner. 

AGC  ADM.1.3C  The  administrator  guidance  shall  contain  warnings  about 

functions  and  privileges  that  should  be  controlled  in  a secure 
processing  environment. 


AGC  ADM.1.4C 


The  administrator  guidance  shall  describe  all  assumptions 
regarding  user  behavior  that  are  relevant  to  secure  operation  of 


the  TOE. 


AGC  ADM.1.5C  The  administrator  guidance  shall  describe  all  security 

parameters  under  the  control  of  the  administrator,  indicating 
secure  values,  as  appropriate. 

AGC  ADM.1.6C  The  administrator  guidance  shall  describe  each  type  of  security- 
relevant event  relative  to  the  administrative  functions  that  need 
to  be  performed,  including  changing  the  security  characteristics 
of  entities  under  the  control  of  the  TSF. 


AGC  ADM.1.7C  The  administrator  guidance  shall  be  consistent  with  all  other 
documentation  supplied  for  evaluation. 

AGC  ADM.1.8C  The  administrator  guidance  shall  describe  all  security 

requirements  for  the  IT  environment  that  are  relevant  to  the 
administrator. 


AGD  ADM. 1. IE 


The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 
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User  Guidance  (AGDUSR.l) 


Dependencies: 

ASD_SAD.  1 Operational  System  Architecture  Design 

AGD  USR.1.1D 

The  developer  shall  provide  user  guidance. 

AGDUSR.1.1C 

The  user  guidance  shall  describe  the  functions  and  interfaces 
available  to  the  non-administrator  users  of  the  System  TOE. 

AGD  USR.1.2C 

The  user  guidance  shall  describe  the  use  of  user-accessible 
security  functions  provided  by  the  System  TOE. 

AGD  USR.1.3C 

The  user  guidance  shall  contain  warnings  about  user-accessible 
functions  and  privileges  that  should  be  controlled  in  a secure 
processing  environment. 

AGD  USR.1.4C 

The  user  guidance  shall  clearly  present  all  user  responsibilities 
necessary  for  secure  operation  of  the  TOE,  including  those 
related  to  assumptions  regarding  user  behavior  found  in  the 
statement  of  the  TOE  security  environment. 

AGDUSR.1.5C 

The  user  guidance  shall  be  consistent  with  all  other 
documentation  supplied  for  evaluation. 

AGDUSR.1.6C 

The  user  guidance  shall  describe  all  security  requirements  for 
the  IT  environment  that  are  relevant  to  the  user. 

AGDUSR.1.1E 

The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 

System  Operational  Configuration  Definition  Guidance  (AGD  OCD.l) 


Dependencies: 

ASD  SAD.  1 Operational  System  Architecture  Design 

ASD  COM.l  Operational  System  Security  Concept  of  Operations 

AGD  OCD.1.1D 

The  developer/integrator/system  owner  shall  provide  configuration 
guidance  that  defines  the  security  relevant  configuration  parameters 
that  support  the  integration  of  the  system  components  and  that  allow 
the  system  security  functions  to  implement  and  enforce  the  system 
security  concept  of  operations  and  associated  policies. 

AGD  OCD.1.1C 

The  configuration  guidance  shall  describe  the  security  configuration 
parameters  available  to  the  system  integrator  or  equivalent 
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users/administrator  of  the  System  TOE  with  that  role  and 
responsibility. 


AGD  OCD.1.2C 


The  configuration  guidance  shall  describe  the  use  of  security 
parameters  configurable  by  the  TOE  to  implement  and  enforce 
the  system  security  policies. 


AGD  OCD.1.3C  The  configuration  guidance  shall  contain  warnings  about 

configuration  accessible  functions  and  privileges  that  should  be 
controlled  in  a secure  processing  environment. 


AGD  OCD.1.4C  The  configuration  guidance  shall  clearly  present  all 

configuration  related  responsibilities  necessary  for  secure 
operation  of  the  TOE. 


AGD  OCD.1.5C  The  user  guidance  shall  be  consistent  with  all  other 
documentation  supplied  for  evaluation. 


AGD  OCD.1.6C  The  configuration  guidance  shall  describe  all  security 
requirements  relative  to  the  System  environment. 


AGD  OCD.1.1E 


The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 


8.2 ,4 


Identification  of  Security  Measures  (ALC  DVS.l) 
Dependencies:  No  dependencies. 


ALC  DVS.l. ID  The  developer  shall  produce  development  security  documentation. 


ALC  DVS.l. 1C 


The  development  security  documentation  shall  describe  all  the 
physical,  procedural,  personnel,  and  other  security  measures  that  are 
necessary  to  protect  the  confidentiality  and  integrity  of  the  TOE 
design  and  implementation  in  its  development  environment. 


ALC  DVS.1.2C  The  development  security  documentation  shall  provide  evidence 
that  these  security  measures  are  followed  during  the 
development  and  maintenance  of  the  TOE. 
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ALC  DVS.1.1E 


The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 


ALC  DVS.1.2E  The  evaluator  shall  confirm  that  the  security  measures  are  being  applied. 


Systematic  Flaw  Remediation  (ALCFLR.3) 


Dependencies:  No  dependencies. 


ALC  FLR.3.1D 


The  developer  shall  provide  flaw  remediation  procedures  addressed  to 
TOE  developers. 


ALC  FLR.3.2D 


The  developer  shall  establish  a a procedure  for  accepting  and  acting  upon 
all  reports  of  security  flaws  and  requests  for  corrections  to  those  flaws. 


ALC  FLR.3.3D 


The  developer  shall  provide  remediation  guidance  addressed  to  TOE 
users. 


ALC  FLR.3.1C 


The  flaw  remediation  procedures  documentation  shall  describe  the 
procedures  used  to  track  all  reported  security  flaws  in  each  release  of  the 


TOE. 


ALC  FLR.3.2C 


The  flaw  remediation  procedures  shall  require  that  a description  of 
the  nature  and  effect  of  each  security  flaw  be  provided,  as  well  as 
the  status  of  finding  a correction  to  that  flaw. 


ALC  FLR.3.3C 


The  flaw  remediation  procedures  shall  require  that  corrective 
actions  be  identified  for  each  of  the  security  flaws. 


ALC  FLR.3.4C 


The  flaw  remediation  procedures  documentation  shall  describe  the 
methods  used  to  provide  flaw  information,  corrections  and  guidance 
on  corrective  actions  to  TOE  users. 


ALC  FLR.3.5C 


The  flaw  remediation  procedures  documentation  shall  describe  a 
means  by  which  the  developer  receives  from  TOE  users  reports  and 
enquiries  of  suspected  security  flaws  in  the  TOE. 


ALC  FLR.3.6C  The  procedures  for  processing  reported  security  flaws  shall  ensure 
that  any  reported  flaws  are  corrected  and  the  correction  issued  to 
TOE  users. 


ALC  FLR.3.7C  The  procedures  for  processing  reported  security  flaws  shall  provide 
safeguards  that  any  correction  to  these  security  flaws  do  not 
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introduce  any  new  flaws. 


ALC  FLR.3.8C 


The  flaw  remediation  guidance  shall  describe  a means  by  which 
TOE  users  report  to  the  developer  any  suspected  security  flaws  in 


the  TOE. 


ALC  FLR.3.9C 


The  flaw  remediation  procedures  shall  include  a procedure 
requiring  timely  responses  for  the  automatic  distribution  of 
security  flaw  reports  and  the  associated  corrections  to 
registered  users  who  might  be  affected  by  the  security  flaw. 


ALC  FLR.3.10C 


The  flaw  remediation  guidance  shall  describe  a means  by  which 
TOE  users  may  register  with  the  developer,  to  be  eligible  to 
receive  security  reports  and  corrections. 


ALC  FLR.3.11C 


The  flaw  remediation  guidance  shall  identify  the  specific  points 
of  contact  for  all  reports  and  enquiries  about  security  issues 
involving  the  TOE. 


ALC  FLR.3.1E 


The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 


Adequacy  of  Operational  Security  Measures  (ALC  OPS.2) 


Dependencies:  ASD  COM.l  Operational  System  Security  Concept  of  Operations 


ALC  OPS.2. ID 


The  developer/integrator/svstem  owner  shall  produce  operations 
security  documentation. 


ALC  OPS.2. 1C 


The  operations  security  documentation  shall  describe  all  the  physical, 
procedural,  personnel,  and  other  security  controls  measures  that  are 
required  to  protect  the  integrity  of  the  System  TOE  implementation 
in  its  operational  environment. 


ALC  OPS2.2C 


The  operations  security  documentation  shall  provide  evidence  that 
these  security  control  measures  are  in  place,  followed,  and  enforced 
during  the  operations  and  maintenance  of  the  System  TOE. 


ALC  OPS.2.3C 


The  evidence  shall  provide  support  that  the  security  control 
measures,  as  implemented,  provide  the  required  level  of  protection  to 
maintain  effective  security  of  the  System  TOE. 


ALC  OPS.2. IE 


The  evaluator  shall  confirm  that  the  information  provided  meets  all 
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ALC  OPS.2.2E 


requirements  for  content  and  presentation  of  evidence. 

The  evaluator  shall  confirm  that  the  security  controls  measures  are 
being  applied. 


areness  (ASA) 


Verified  Operational  Security  Guidance  (ASA  PPG. 2) 


Dependencies: 

ASAPPG.2.1D 

ASA  PPG.2.1C 


No  dependencies. 

The  system  owner/management  shall  provide  security  policy 
and  procedure  guidance  addressed  to  [selection:  [assignment: 
appropriate  personnel  definition |,  all\  personnel. 

The  security  policy  and  procedure  guidance  shall  describe  the 
security  policies  applicable  to  the  system  for  the  target  personnel 


ASA  PPG.2.2C 


The  security  policy  and  procedure  guidance  shall  describe  how 
personnel  can  obtain  the  full  contents  of  the  security  policies 
applicable  to  the  system  for  the  target  personnel 


ASA  PPG. 2. IE 


The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 


ASA  PPG.2.2E 


The  evaluator  shall  independently  verify  through  [selection:  personnel 
interviews , sampling  the  procedures  in  the  security  policy  and  procedure 
guidance , [assignment:  other  methods ]]  the  veracity  of  the  contents  of 
the  security  policy  and  procedures  guidance. 


Security  Contn 


Security  Policy,  Procedures  and  Organization  (ASC  PPO.l) 


Dependencies: 

ASC  PPO.l.lD 


No  dependencies. 

The  system  owner  shall  provide  operational  security 
documentation. 
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ASC  PPO.l.lC 


The  security  controls  documentation  shall  describe  all  the  policy, 
procedural,  personnel,  and  related  organisational  security  controls 
measures  that  are  necessary  to  protect  the  confidentiality  and 
integrity  of  the  operations  and  maintenance  of  the  System  TOE  in  its 
operational  environment. 


ASC  PP0.1.2C 


The  operations  security  documentation  shall  provide  evidence  that 
these  security  controls  measures  are  followed  during  the  operation 
and  maintenance  of  the  System  TOE. 


ASC  PPO.l.lE 


The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 


ASC  PP0.1.2E 


The  evaluator  shall  confirm  that  the  security  controls  are  being 
applied. 


Physical,  Facility  and  Assets  (ASC  PFA.l) 


Dependencies: 

ASC  PFA.l. ID 

ASC  PFA.l. 1C 


No  dependencies. 

The  developer/system  owner/integrator  shall  provide 
documentation  for  the  physical,  facility,  and  assets  that 
comprise  the  System  security  controls. 

The  security  controls  documentation  shall  describe  all  the  physical, 
facility  and  assets  related  security  controls  measures  that  are 
necessary  to  protect  the  confidentiality  and  integrity  of  the  operations 
and  maintenance  of  the  System  TOE  in  its  operational  environment. 


ASC  PFA.1.2C 


The  operations  security  documentation  shall  provide  evidence  that 
these  physical  security  controls  measures  are  followed  during  the 
operation  and  maintenance  of  the  System  TOE. 


ASC  PFA.l. IE 


The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 


ASC  PFA.1.2E 


The  evaluator  shall  confirm  that  the  physical  security  controls  are 
being  applied  effectively. 


Operational  Integration  (ASC  OIN.l ) 
Dependencies:  No  dependencies. 
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ASCOIN.1.1D 
ASC  OIN.1.1C 


The  developer/system  owner/integrator  shall  provide  operational 
security  documentation. 

The  operational  system  security  documentation  shall  describe  the 
integrated  system  security  controls;  to  include  IT  and  physical,  policy, 
procedural,  personnel,  and  other  system  security  measures  that  are 
necessary  to  protect  the  confidentiality  and  integrity  of  the  operations 
and  maintenance  of  the  System  TOE  in  its  operational  environment. 


ASC  OIN.1.2C 


The  operations  security  documentation  shall  provide  evidence  that 
the  integrated  security  control  measures  are  followed  as  part  of  the 
operations  and  maintenance  of  the  System  TOE. 


ASC  OIN.1.3C 


The  evidence  shall  justify  the  integrated  security  measures  provide 
the  necessary  level  of  protection  to  maintain  the  confidentiality  and 
integrity  of  the  System  TOE. 


ASC  OIN.1.1E 


The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 


ASC  OIN.1.2E 


The  evaluator  shall  confirm  that  the  integrated  system  security 
measures  are  being  applied. 


LI! 


Operational  System  Architecture  Design  (ASDSAD.l ) 
Dependencies:  No  dependencies. 


ASD  SAD.1.1D  The  developer/integrator  shall  provide  an  architecture  description. 


ASD  SAD.1.1C 


The  architecture  description  shall  identify  the  system  in  terms  of  its 
subsystems  and  critical  components  and  the  interfaces  and 
interconnects  between  the  subsystems  and  critical  components. 


ASD  SAD.1.2C 


The  architecture  description  shall  identify  the  super-systems  that 
interact  with  the  system  and  the  interfaces  and  interconnects  between 
the  system  and  the  super-systems. 


ASD  SAD.1.3C 


The  architecture  description  shall  describe  the  purpose  of  the 
identified  subsystems,  critical  components,  interconnects  and 
interfaces  of  the  system. 


ASD  SAD.1.4C 


The  architecture  description  shall  describe  the  purpose  of  the 
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identified  interconnects  and  interfaces  from  the  system  to  super- 
systems and  shall  describe  the  services  from  and  provided  to  the 
super-systems. 


ASD  SAD.1.1E 


The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 


ASD  SAD.1.2E 


The  evaluator  shall  determine  that  the  architecture  description  is 
consistent  with  the  interface  functional  specification. 


Operational  System  Interface  Functional  Specification  (ASD  IFS.l) 


Dependencies:  No  dependencies. 


ASD  IFS.1.1D 

ASD  IFS.l. 1C 


The  developer/integrator  shall  provide  an  interface  functional 
specification. 

The  interface  functional  specification  shall  describe  the  operational 
system  security  functions. 


ASD  IFS.1.2C  The  interfaces  functional  specification  shall  be  internally  consistent. 


ASD  IFS.1.3C 


The  interface  functional  specification  shall  identify  and  describe  all 
the  external  system  security  function  interfaces,  including  the 
behaviour  of  those  interfaces. 


ASD  IFS.1.4C 

ASD  IFS.l. IE 


The  interface  functional  specification  shall  cover  all  the  system 
security  functions. 

The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 


ASD  IFS.1.2E 


The  evaluator  shall  determine  whether  the  interface  functional 
specification  is  a complete  instantiation  of  the  system  security 
functional  requirements. 


Subsystem  Design  Allocation  (ASD  SSD.2) 


Dependencies:  ASD  SSD.l  Subsystem  design. 

ASD  SSD.2.1D  The  developer/integrator  shall  provide  a subsystem  design. 
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ASD  SSD.2.1C  The  subsystem  design  shall  be  internally  consistent. 


ASD  SSD.2.2C 


The  subsystem  design  shall  allocate  the  portion  of  the  SSF  to  each 
represented  subsystem  in  terms  of  minor  and  major  subsystems. 


ASD  SSD.2.3C 


The  subsystem  design  shall  describe  the  security  functionality 
provided  by  each  subsystem. 


ASD  SSD.2.4C 


The  subsystem  design  shall  identify  all  hardware,  firmware,  and 
software  required  by  the  SSF  allocated  to  the  subsystem. 


ASD  SSD.2.5C 


The  subsystem  design  shall  allocate  the  portion  of  the  SSF  to  each 
represented  subsystem  in  terms  of  minor  and  major  subsystems. 


ASD  SSD.2.6C 


The  subsystem  design  shall  identify  the  interfaces  to  the  subsystem 
security  functions. 


ASD  SSD.2.7C 


The  subsystem  design  shall  describe  the  interfaces  to  each  subsystem, 
in  terms  of  their  purpose  and  method  of  use  of  the  effects,  exceptions 
and  error  messages. 


ASD  SSD.2.1E 


The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 


ASD  SSD.2.2E 


The  evaluator  shall  determine  whether  the  subsystem  design  is  a 
complete  instantiation  of  the  operational  system  security  functional 
requirements. 


Implementation  Representation  (ASD  IMP.  1 ) 


Dependencies: 

ASD  IMP.1.1D 

ASD  IMP.1.1C 


No  dependencies. 

The  developer/integrator  shall  provide  an  implementation 
representation  of  the  system  design. 

The  implementation  representation  shall  be  internally  consistent. 


ASD  IMP.1.2C 


The  implementation  representation  identify  the  system  functionality, 
and  the  system  components  that  when  integrated  provide  that 
functionality  to  the  operational  system. 


ASD  IMP.1.3C 


The  implementation  representation  shall  describe  the  security 
functionality  provided  by  the  integration  of  each  component  in  terms 
of  its  specific  configuration  requirements. 
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ASD  IMP.1.4C 


The  implementation  representation  shall  identify  any  hardware, 
firmware,  and  software  integration  and  configuration  issues,  as 
identified,  prior  to,  or  during  the  operational  system  evaluation,  that 
will  need  to  be  revisited. 


ASD  IMP.1.5C 


The  implementation  representation  shall  identify  the  integrated 
components  and  their  required  configuration  to  the  system  security 
functions. 


ASD  IMP.1.1E 


The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 


ASD  IMP.1.2E 


The  evaluator  shall  determine  whether  the  implementation 
representation  is  a complete  instantiation  of  the  integrated 
operational  system  security  functional  requirements. 


Operational  System  Security  Concept  of  Operations  (ASD  COM.l) 


Dependencies:  No  dependencies. 


ASD  COM.1.1D 

ASD  COM.1.2D 


The  system  owner/management  shall  provide  a system  operations 
policy  documents. 

The  system  owner/integrator  shall  incorporate  system  policy 
enforcement  requirements  and  capabilities  into  the  policy  documents 
provided  by  the  system  management,  and  provide  the  system 
operations  policy  documents  with  the  system  enforcement 
capabilities,  and  their  bounds. 


ASD  COM. 1. 1C 


The  system  concept  of  operations  and  enforcement  documents 
subsystem  shall  be  internally  consistent. 


ASD  COM.1.2C 


The  operational  system  operations  policy  documents  shall  identify  the 
system  capabilities  for  enforcement  of  information  flow  across  the 
operational  system  interconnects  within  the  operational  system 
boundaries. 


ASD  COM.1.3C 


The  operational  system  operations  policy  documents  shall  identify  the 
system  capabilities  for  enforcement  of  information  flow  across  the 
operational  system  interconnects  to  external  operational  systems. 


ASD  COM.1.4C 


The  operational  system  operations  policy  documents  shall  identify  the 
system  capabilities  for  enforcement  of  local  and  remote  access  to  the 
operational  system. 
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ASD  COM.1.5C 


The  operational  system  operations  policy  documents  shall  identify  the 
system  capabilities  for  enforcement  of  access  to  operational  system 
resources  based  upon  access  mediation  rules. 


ASD  COM.1.6C 


The  operational  system  operations  policy  documents  shall  identify  the 
modes  of  operation  provided  by  the  system,  and  the  enforcement 
mechanisms  to  prov  ide  secure  operations  in  each  of  the  identified 
system  modes  of  operation. 


ASD  COM.2.1E 


The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 


ASD  COM.2.2E 


The  evaluator  shall  determine  whether  the  system  design  is  a 
complete  instantiation  of  the  operational  system  security  concept  of 
operations  in  support  of  the  operational  mission. 


System  Security  Controls  Testing  (ATE  AST.3) 


Dependencies: 


ATE  AST.3.1D 

ATE  AST.3.2D 

ATE  AST.3.3D 

ATE  AST.3.1C 


AGD  OCD.l  System  operational  configuration  definition. 

AGD  USR.  1 User  guidance 

ASD  IFS.l  System  interface  functional  definition 

ASD  IMP.  1 Implementation  representation 

The  developer/integrator  shall  provide  evidence  of  test  verification 
planning. 

The  developer/integrator  shall  provide  an  analysis  of  level  of  detail  of 
integrated  security  controls  testing. 

The  developer  shall  provide  test  documentation  and  the  the  System 
TOE  for  testing. 

The  analysis  of  the  security  controls  verification  shall  demonstrate 
that  the  correspondence  between  the  security  controls  as  identified  in 
the  SST  and  the  tests  identified  in  the  test  documentation  is  complete. 


ATE  AST.3.2C 


The  level  of  detail  analysis  shall  show  that  the  integrated  security 
controls  tests  identified  in  the  test  documentation  are  able  to 
sufficiently  demonstrate  that  the  system  security  controls  integrated 
into  the  System  TSF  operates  in  accordance  with  its  high  level  design. 
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ATE  AST.3.3C 


The  level  of  detail  analysis  shall  show  that  the  integrated  security 
controls  tests  identified  in  the  test  documentation  are  able  to 
sufficiently  demonstrate  that  the  system  security  controls  integrated 
into  the  System  TSF;  and  are  a correct  implementation. 


ATE  AST.3.4C  The  System  TOE  shall  be  suitable  for  testing. 


ATE  AST.3.1E 


The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 


ATE  AST.3.2E 


The  evaluator  shall  test  a subset  of  the  system  TSF  to  confirm  that  the 
system  TOE  operates  as  specified  in  its  intended  operational 
environment. 


Analysis  of  Coverage  ( ATE  CO V .2) 


Dependencies:  ASDIFS.l  System  interface  functional  definition 

ATEFUN.l  Functional  testing 


ATE  COV.2.1D 

ATE  COV.2.1C 


ATE  COV.2.2C 


ATE  AST.3.1E 


The  developer/integrator  shall  provide  an  analysis  of  the  test 
coverage. 

The  analysis  of  test  coverage  shall  demonstrate  that  the 
correspondence  between  the  TSF  as  described  in  the  functional 
specification  and  the  tests  identified  in  the  test  documentation  is 
complete. 

The  analysis  of  the  test  coverage  shall  demonstrate  tha  the 
correspondence  between  the  TSF  as  described  in  the  functional 
specification  and  the  tests  identified  in  the  test  documentation  is 
complete. 

The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 


Testing:  high-level  design  (ATE  DPT.  1 ) 


Dependencies: 


ATE  DPT.1.1D 


ASD  IFS.l  System  interface  functional  definition 
ATE  FUN.l  Functional  testing 

The  developer/integrator  shall  provide  an  analysis  of  the  depth  of 
testing. 
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ATE  DPT.1.1C 


ATE  DPT. 1. IE 


The  depth  analysis  shall  demonstrate  that  the  tests  identified  in  the 
test  documentation  are  sufficient  to  demonstrate  that  the  TSF 
operates  in  accordance  with  its  high-level  design. 

The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 


Functional  Testing  (ATE  FUN.  1) 


Dependencies: 

ATE  FUN.1.1D 

ATE  FUN.  1. 2D 


No  dependencies. 

The  developer/integrator  shall  test  the  TSF  and  documents  the 
results. 

The  developer/integrator  shall  provide  test  documentation. 


ATE  FUN.1.1C 


The  test  documentation  shall  consist  of  test  plans,  test  procedure 
descriptions,  expected  test  results  and  actual  test  results. 


ATE  FUN.1.2C 


The  test  plans  shall  identify  the  security  functions  to  be  tested  and 
describe  the  goal  of  the  tests  to  be  performed. 


ATE  FUN.1.3C 


The  test  procedure  descriptions  shall  identify  the  tests  to  be 
performed  and  describe  the  scenarios  for  testing  each  security 
function.  These  scenarios  shall  include  any  ordering  dependencies  on 
the  results  of  other  tests. 


ATE  FUN.1.4C 


The  expected  test  results  shall  show  the  anticipated  outputs  from  a 
successful  execution  of  the  tests. 


ATE  FUN.1.5C 


The  test  results  from  the  developer/integrator  execution  of  the  tests 
shall  demonstrate  that  each  test  security  function  behaved  as 
specified. 


ATE  FUN.  1. IE 


The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 


Independent  testing  - sample  (ATE  IND.2) 

Dependencies:  AGD_USR.l  User  guidance 

ASD  IFS.l  System  interface  functional  definition 
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ATEIND.2.1D 

ATE  IND.2.1C 


ATEFUN.l  Functional  testing 

The  developer/integrator/system  owner  shall  provide  the  TOE  for 
testing. 

The  TOE  shall  be  suitable  for  testing. 


ATE  IND.2.2C 


ATE  IND.2.1E 


The  developer/integrator/system  owner  shall  provide  an  equivalent 
set  of  resources  to  those  that  were  used  in  the 
developer/integrator/system  owner’s  functional  testing  of  the  TSF 

The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 


ATE  IND.2.2E 


The  evaluator  shall  test  a subset  of  the  TSF  as  appropriate  to  confirm  that  the 
TOE  operates  as  specified. 


ATE  IND.2.3E 


The  evaluator  shall  execute  a sample  of  tests  in  the  test  documentation  to 
verify  the  developer  test  results. 


Examination  of  Guidance  (AVA  MSU.l) 


Dependencies:  ADO_IGS.  1 Installation,  generation,  and  start-up  procedures 

AGD _USR.  1 User  guidance 

ASD  IFS.l  Operational  System  Interface  Functional  Specification 

AVA  MSU.l. ID  The  developer/integrator  shall  provide  guidance  documentation. 


AVA  MSU.l. 1C 


The  guidance  documentation  shall  identify  all  possible  modes  of 
operation  of  the  TOE  (including  operation  following  failure  or 
operational  error),  their  consequences  and  implications  for 
maintaining  secure  operation. 


AVA  MSU.l. 2C 


The  guidance  documentation  shall  be  complete,  clear,  consistent  and 
reasonable. 


AVA  MSU.l. 3C 


The  guidance  documentation  shall  list  all  assumptions  about  the 
intended  environment. 
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AVA  MSU.1.4C 


The  guidance  documentation  shall  list  all  requirements  for  external 
security  measures  (including  external  procedural,  physical  and 
personnel  controls). 


AVA  MSU.1.1E 


The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 


AVA  MSU.1.2E 


The  evaluator  shall  repeat  all  configuration  and  installation  procedures 
to  confirm  that  the  TOE  can  be  configured  and  used  securely  using  only 
the  supplied  guidance  documentation. 


AVA  MSU.1.3E 


The  evaluator  shall  determine  that  the  use  of  guidance  documentation 
allows  all  insecure  states  to  be  detected. 


Strength  of  TOE  security  function  evaluation  (AVA  SOF.1 ) 


Dependencies: 


AVA  SOF.1.1D 


AVA  SOF.1.1C 


ASDSSD.2  Subsystem  design  allocation 

ASDIFS.l  Operational  system  interface  functional  specification 
ASDCOM.l  Operational  system  security  concept  of  operations 

The  developer/system  owner/integrator  shall  perform  a strength  of 
TOE  security  function  analysis  for  each  mechanism  identified  in  the 
SST  as  having  a strength  of  TOE  security  function  claim. 

For  each  mechanism  with  a strength  of  TOE  security  function  claim 
the  strength  of  TOE  security  function  analysis  shall  show  that  it  meets 
or  exceeds  the  minimum  strength  level  defined  in  the  SPP/SST. 


AVA  SOF.1.2C 


For  each  mechanism  with  a strength  of  TOE  security  function  claim 
the  strength  of  TOE  security  function  analysis  shall  show  that  it  meets 
or  exceeds  the  specific  strength  of  function  metric  defined  in  the 


SPP/SST. 


AVA  SOF.1.1E 


The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 


AVA  SOF.1.2E  The  evaluator  shall  confirm  that  the  strength  claims  are  correct. 


Developer/System  owner  vulnerability  analysis  (AVA  VLA.l) 
Dependencies:  ASD  SSD.2  Subsystem  design  allocation 
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ASD_IFS.l  Operational  system  interface  functional  specification 
ASD_COM.l  Operational  system  security  concept  of  operations 
AGD_USR.l  User  guidance 


AVA  VLA.1.1D 
AVA  VLA.1.2D 


The  developer/system  owner  shall  perform  a vulnerability  analysis. 

The  developer/system  owner  shall  provide  vulnerability  analysis 
documentation 


AVA  VLA.1.1C 


The  vulnerability  analysis  documentation  shall  describe  the  analysis 
of  the  TOE  deliverables  performed  to  search  for  obvious  ways  n 
which  a user  can  violate  the  TSP. 


AVA  VLA.1.2C 


The  vulnerability  analysis  documentation  shall  describe  the 
disposition  of  obvious  vulnerabilities. 


AVA  VLA.1.3C 


The  vulnerability  analysis  documentation  shall  show,  for  all  identified 
vulnerabilities,  that  the  vulnerability  cannot  be  exploited  in  the 
intended  environment  of  the  TOE. 


AVA  VLA.1.1E 


The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 


AVA  VLA.1.2E 


The  evaluator  shall  conduct  penetration  testing,  building  on  the 
developer/system  owner  vulnerability  analysis,  to  ensure  obvious 
vulnerabilities  have  been  addressed. 


1 1C 


r 


Assurance  Maintenance  (AMA  AMP.l) 


Dependencies: 


No  dependencies. 


AMA  AMP.  1. ID  The  developer/integrator  shall  provide  an  AM  Plan. 


AM  A AMP  1 1C  The  Plan  contain  or  reference  a brief  description  of  the 
- TOE  including  the  security  functionality  it  provides. 


AMA  AMP.1.2C 


The  AM  Plan  shall  identify  the  certified  version  of  the  system  TOE, 
and  shall  reference  the  evaluation  results.. 
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AMA  AMP.1.3C 


The  AM  Plan  shall  reference  the  TOE  component  categorization 
report  for  the  certified  version  of  the  TOE. 


AMA  AMP.1.4C 


The  AM  Plan  shall  define  the  scope  of  changes  to  the  STOE  that  are 
covered  by  the  plan. 


AM  A AMP.1.5C 


The  AM  Plan  shall  describe  the  TOE  life-cycle,  and  shall  identify  the 
current  plans  for  any  new  releases  of  the  TOE,  together  with  a brief 
description  of  any  planned  changes  that  are  likely  to  have  a 
significant  security  impact. 


AMA  AMP.1.6C 


The  AM  Plan  shall  describe  the  assurance  maintenance  cycle,  stating 
and  justifying  the  planned  schedule  of  AM  audits  and  the  target  date 
of  the  next  re-evaluation  of  the  TOE. 


AMA  AMP.1.7C 


The  AM  Plan  shall  identify  the  individual(s)  who  will  assume  the  role 
of  developer/system  owner  security  analyst  for  the  system  TOE. 


AMA  AMP.1.8C 


The  AM  Plan  shall  describe  how  the  developer/system  owner  security 
analyst  role  will  ensure  that  the  procedures  documented  or  referenced 
in  the  AM  Plan  are  followed. 


AMA  AMP.1.9C 


The  AM  Plan  shall  describe  how  the  developer/system  owner  security 
analyst  role  will  ensure  that  all  developer/integrator  actions  involved 
in  the  analysis  of  the  security  impact  of  changes  affecting  the  TOE  are 
performed  correctly. 


AMA  AMP  1 IOC  The  AM  Plan  shall  justify  why  the  identified  developer/system  owner 
security  analyst(s)  have  sufficient  familiarity  with  the  security  target, 
functional  specification  and  (where  appropriate)  high  level  design  of 
the  TOE,  and  with  the  evaluation  results  and  all  applicable  assurance 
requirements  for  the  certified  version  of  the  TOE. 

4MA  AMP  1 11C  The  AM  Plan  shall  describe  or  reference  the  procedures  to  be  applied 
to  maintain  the  assurance  in  the  TOE,  which  shall  include  the 
procedures  for  configuration  management,  maintenance  of  assurance 
evidence,  performance  of  the  analysis  of  the  security  impact  of 
changes  affecting  the  TOE,  and  flaw  remediation. 


4MA  AMP  1 IE  The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 


AMA  AMP.1.2E  The  evaluator  shall  confirm  that  the  proposed  schedules  for  AM  audits  and 
re-evaluation  of  the  TOE  are  acceptable  and  consistent  with  the  proposed 
changes  to  the  TOE. 


System  Protection  Profile  - Industrial  Control  Systems 
Version  1.0 


Page  86  of  151 


National  Institute  of  Standards  & Technology 
System  Protection  Profile  - Industrial  Control  Systems 


NIST 

MaHonn!  tnstttw?*  ©1 
$1orvdor«U  and  Iwcftnology 


TOE  component  categorization  report  ( AM  A CAT.  1 ) 


Dependencies:  ACM  CAP.2  Configuration  items 


AMA  CAT.  1.1  D 

AMA  CAT.1.1C 


The  developer/system  owner  shall  provide  a system  TOE  component 
categorization  report  for  the  certified  version  of  the  system  TOE. 

The  TOE  component  categorization  report  shall  categorize  each 
component  of  the  system  TOE,  identifiable  in  each  TSF 
representation  from  the  most  abstract  to  the  least  abstract,  according 
to  its  relevance  to  security;  system  TOE  component  categorization 
must  indicate  whether  the  component  is  TSP-enforcing  or  non-TSP 
enforcing. 


AMA  CAT.  1.2C 


The  system  TOE  component  categorization  report  shall  describe  the 
categorization  scheme  used,  so  that  it  can  be  determined  how  to 
categorize  new  components  introduce  into  the  system  TOE,  and  also 
when  to  re-categorize  existing  system  TOE  components  following 
changes  to  the  system  TOE  or  its  security  target. 


AMA  CAT.  1.3C 


The  system  TOE  component  categorization  report  shall  identify  any 
tools  used  in  the  development  or  operational  environment  that,  if 
modified,  will  have  an  impact  on  the  assurance  that  the  system  TOE 
satisfies  its  security  target. 


AMA  CAT.  1.1E 


The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 


AMA  CAT.  1.2E 


The  evaluator  shall  confirm  that  the  categorization  of  system  TOE 
components  and  tools,  and  the  categorization  scheme  used,  are 
appropriate  and  consistent  with  the  evaluation  results  for  the  certified 
version. 


Evidence  of  maintenance  process  (AMA  EVD.i) 


Dependencies:  AMA  AMP.l  Assurance  maintenance  process 

AMA_SIA.  1 Sampling  of  security  impact  analysis 


AMA  EVD.I. ID 


The  developer/system  owner  security  analyst  shall  provide  AM 
documentation  for  the  current  version  of  the  TOE. 


AMA  EVD.I. 1C 


The  AM  documentation  shall  include  a configuration  list  that 
comprises  the  current  version  of  the  TOE. 
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The  configuration  list  shall  describe  the  configuration  items  that 
comprise  the  current  version  of  the  TOE. 


AMA  E\T).1.3C 


The  AM  documentation  shall  provide  evidence  that  the  procedures 
documented  or  referenced  in  the  AM  Plan  are  being  followed. 


AMA  EVD.1.4C 


The  list  of  identified  vulnerabilities  in  the  current  version  of  the  TOE 
shall  show,  for  each  vulnerability,  that  the  vulnerability  cannot  be 
exploited  in  the  intended  environment  for  the  TOE. 


AMA  EVD.1.1E 


The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 


AMA  EVD.1.2E 


The  evaluator  shall  confirm  that  the  procedures  documented  or 
referenced  in  the  AM  Plan  are  being  followed. 


AMA  EVD.1.3E 


The  evaluator  shall  confirm  that  the  security  impact  analysis  for  the 
current  version  of  the  TOE  is  consistent  with  the  configuration  list. 


AMA  EVD.1.4E 


The  evaluator  shall  confirm  that  all  changes  documented  in  the  security 
impact  analysis  for  the  current  version  of  the  TOE  are  within  the  scope 
of  changes  covered  by  the  AM  Plan. 


AMA  EVD.1.5E 


The  evaluator  shall  confirm  that  functional  testing  has  been  performed 
on  the  current  version  of  the  Toe,  to  a degree  commensurate  with  the 
level  of  assurance  being  maintained. 


Sampling  of  security  impact  analysis  (AMAJSIA.l) 


Dependencies:  AMA  CAT.l  TOE  component  categorization  report 


AMA  SIA.1.1D 


AMA  SIA.1.1C 


The  developer/system  owner  security  analyst  shall,  for  the  current 
version  of  the  TOAE,  provide  a security  impact  analysis  that  covers 
all  changes  affecting  the  TOE  as  compared  with  the  certified  version. 

The  security  impact  analysis  shall  identify  the  certified  TOE  from 
which  the  current  version  of  the  TOE  was  derived. 


AMA  SIA  1 2C  The  secur*ty  impact  analysis  shall  identify  all  new  and  modified  TOE 
components  that  are  categorised  as  TSP-enforcing. 


AMA  SI  4.1  3C  The  secur*ty  impact  analysis  shall,  for  each  change  affecting  the 

security  target  or  TSF  representations,  briefly  describe  the  change 
and  any  effects  it  has  on  lower  representation  levels. 
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AMASIA.1.4C 

The  security  impact  analysis  shall,  for  each  change  affecting  the 
security  target  or  TSF  representations,  identify  all  IT  security 
functions  and  all  TOE  components  categorised  as  TSF  enforcing  that 
are  affected  by  the  change. 

AMA  SIA.1.5C 

The  security  impact  analysis  shall,  for  each  change  which  results  in  a 
modification  of  the  implementation  representation  of  the  TSF  or  the  IT 
environment,  identify  the  test  evidence  that  shows,  to  the  required  level 
of  assurance,  that  the  TSF  continues  to  be  correctly  implemented 
following  the  change. 

AMA  SIA.1.6C 

The  security  impact  analysis  shall  for  each  applicable  assurance 
requirements  in  the  configuration  management  (ACM),  life  cycle 
support  (ALC),  delivery  and  operation  (ADO),  and  guidance  documents 
(AGD)  assurance  classes,  identify  any  evaluation  deliverables  that  have 
changed,  and  provide  a brief  description  of  each  change  and  its  impact 
on  assurance. 

AMA  SIA.1.7C 

The  security  impact  analysis  shall  for  each  applicable  assurance 
requirement  in  the  vulnerability  assessment  (AVA)  assurance  class, 
identify  which  evaluation  deliverables  have  changed  and  which  have  not, 
and  give  reasons  for  the  decision  taken  as  to  whether  or  not  to  update  the 
deliverable. 

AMA  SIA.1.1E 

The  evaluator  shall  confirm  that  the  information  provided  meets  all 
requirements  for  content  and  presentation  of  evidence. 

AMA  SIA.1.2E 

The  evaluator  shall  confirm,  by  sampling  that  the  security  impact 
analysis  documents  changes  to  an  appropriate  level  of  detail,  together 
with  appropriate  justifications  that  assurance  has  been  maintained  in  the 
current  version  of  the  TOE. 

6.3  Security  Requirements  for  the  IT  Environment 

The  STOE  has  no  requirements  for  the  external  IT  environment,  other  than  those 
stipulated  by  the  organizational  security  policies  (refer  to  section  3.3). 

6.4  Security  Requirements  for  the  Non-IT  Environment 

The  STOE  has  no  requirements  for  the  external  non-IT  environment,  other  than  those 
stipulated  by  the  organizational  security  policies  (refer  to  section  3.3). 
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7 SPP  Application  Notes 

This  section  of  the  document  contains  supporting  information  that  will  be  useful  in  developing 
more  focused  system  protection  profiles  (SPPs)  or  system  security  targets  (SSTs)  for  specific 
classes  of  industrial  control  systems,  for  example  SCADA  systems,  or  for  specific  applications  of 
industrial  control  systems. 

7.1  SPP  Overview 


A System  Protection  Profile  provides  an  implementation-independent  set  of  security  requirements 
for  a category  of  one  or  more  systems.  Unlike  a traditional  Protection  Profile  (PP)  that  focuses 
on  the  IT  security  requirements  for  a product,  a SPP  also  captures  management  and  operational 
security  requirements  to  ensure  the  overall  effectiveness  of  a system’s  security  regime. 
Collectively,  these  requirements  are  referred  to  as  the  technical,  operational  and  management 
security  requirements  of  a system. 

The  term  system  is  defined  as  the  combination  of  physical,  personnel,  procedures  and  processes 
(derived  from  the  operational  and  management  security  requirements)  integrated  with 
technology-based  functions  and  mechanisms  (derived  from  the  technical  security  requirements), 
applied  together  to  establish  an  acceptable  level  of  residual  risk  in  a defined  operational 
environment. 

This  SPP  has  documented  the  minimum  set  of  security  requirements  applicable  to  a generic 
industrial  control  system.  However,  while  this  document  has  attempted  to  model  a “generic” 
ICS,  it  is  acknowledged  that  not  all  security  requirements  will  apply  to  all  ICS  instantiations. 
Where  compliance  to  a set  of  security  requirements  for  a specific  ICS  is  required,  another  SPP 
should  be  written  to  address  specific  industry  needs.  A discussion  of  this  relationship  between 
the  SPP-ICS  and  further  SPPs  and  SSTs  follows. 

As  shown  by  Figure  3 below,  the  SPP-ICS  can  be  viewed  as  a high-level  object  in  an  object-class 
hierarchy.  In  this  case,  the  high-level  object  is  the  SPP-ICS  and  lower-level  objects  can  take  the 
form  of  one  or  more  SPPs  or  SSTs. 
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Figure  3 - Relationship  between  SPP-ICS  and  other  potential  SPP’s  and  SST's 

In  the  case  of  a lower-level  SPP,  one  may  use  the  security  requirements  in  the  SPP-ICS  as  a 
baseline  for  further  refinement.  The  end  result  will  produce  an  SPP  addressing  the  security  needs 
of  a particular  ICS  type  (e.g.  SCADA).  Alternatively,  an  SST  author  may  claim  compliance  to 
the  SPP-ICS  by  writing  an  SST  based  on  the  SPP-ICS.  In  this  latter  case,  the  SST  author  should 
be  aware  that  further  refinement  is  still  required  to  claim  conformance.  Such  refinements  for 
either  a lower-level  SPP  or  a compliant  SST  have  been  discussed  later  in  this  section. 

Regardless  of  how  the  SPP-ICS  is  applied,  the  SPP-ICS  has  been  developed  to  be  flexible  and 
scalar  in  nature.  That  is,  the  SPP-ICS  may  be  refined  to  address  an  entire  ICS  system,  or  be 
refined  to  address  the  security  needs  of  specific  subsystems  commonly  used  in  the  process  control 
industry. 

Finally,  it  is  envisaged  that  the  SPP-ICS  will  be  used  to  help  ensure  interoperability  between 
process  control  systems,  provide  for  a consistent  implementation  of  security  controls  across 
systems  and  maintain  a level  of  confidence  in  the  security  functions  and  mechanisms  used  to 
protect  ICS  systems  and  their  related  assets. 


The  structure  of  the  SPP-ICS  has  been  developed  following  the  specification  of  protection 
profiles  defined  by  the  Common  Criteria.  However,  as  the  SPP-ICS  is  a system  PP,  the  authors 
have  extended  the  specification  to  incorporate  several  differences  unique  to  systems  that  are  not 
typically  found  in  product-based  protection  profile  specifications.  These  differences,  and  their 
relationships  to  the  main  elements  defined  by  the  SPP-ICS,  have  been  captured  below  in  Figure 
4. 

A discussion  of  each  of  the  elements  and  their  interrelationships  in  the  SPP-ICS  is  provided 
below.  Please  note  that  each  of  these  elements  correspond  to  a different  chapter  in  the  SPP-ICS. 
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Figure  4 - SPP-ICS  Structure 
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7. 1.2.1  Security  Environment  (Chapter  3) 

The  security  environment  describes  the  security  aspects  of  the  ICS  operational  environment. 
As  for  any  CC-based  specification,  the  SPP-ICS  contains  a statement  of  the  assumptions, 
threats  and  organizational  security  policies  applicable  to  the  STOE.  However,  the  SPP-ICS 
has  expanded  the  definition  of  threats  to  include  the  following  attributes: 

■ Threat  Agents  conducting  an  attack  against  the  assets  protected  by  the  STOE.  A 
threat  agent  is  characterized  by  the  following: 

o The  level  of  expertise  of  the  agent 
o The  resources  available  to  the  agent  to  stage  the  attack 
o The  motivation  of  the  agent 

■ An  attack  which  is  characterized  by  the  following: 

o The  method  used  by  the  threat  agent  to  perform  the  attack 
o The  vulnerabilities  exploited  to  gain  access  to  the  protected  assets 
o The  window  of  opportunity  open  to  the  threat  agent  to  conduct  the  attack 

■ The  asset  (protected  by  the  STOE)  that  is  subject  to  the  attack 
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This  approach  to  specifying  the  threats  reduces  ambiguity.  It  also  allows  the  SST  author  to 
thoroughly  understand  the  nature  of  the  threat  so  that  a variety  of  security  controls  can  be 
deployed  to  counter  the  threat. 

7. 1.2.2  Security  Risks  (Chapter  4) 

The  security  risks  are  a further  instantiation  of  the  security  problem.  The  element  of  risk  is 
captured  by  the  SPP-ICS  to  determine  the  relative  importance  of  the  security  needs  of  the  STOE 
and  its  operating  environment.  They  also  guide  the  specification  of  the  security  objectives  by 
ensuring  that  only  those  security  needs  seen  as  critical  to  the  organization  are  addressed  by  the 
STOE  or  its  operating  environment. 

Each  risk  is  a product  of  asset  value,  assessed  level  of  relevant  threats,  and  associated 
vulnerabilities  (as  identified  by  the  security  environment).  It  represents  the  potential  that  a given 
threat  will  exploit  vulnerabilities  to  cause  loss  or  damage  to  an  asset  or  group  of  assets,  and  hence 
directly  or  indirectly  to  the  organization  responsible  for  the  ICS. 

Please  note  that  the  SPP-ICS  has  only  listed  the  categories  of  risks  applicable  to  a generic  ICS. 
Guidance  on  the  identification  of  the  risks  within  these  categories  can  be  found  in  section  7.3.2. 1 . 


7. 1.2.3  Security  Objectives  (Chapter  5) 

The  security  objectives  are  a concise  statement  of  the  intended  response  to  the  security  problem. 
In  order  to  ensure  a cost-effective  system  design,  the  inclusion  of  any  security  objective  should  be 
based  on  the  outcomes  of  a risk  assessment.  For  the  purposes  of  the  SPP-ICS,  it  is  assumed  that 
the  owner  of  the  ICS  has  a well-developed  risk  management  process  capable  of  identifying  the 
risks  to  the  ICS  assets.  Once  identified,  the  risks  should  be  prioritized  and  the  organization’s 
management  should  determine  how  best  to  treat  those  risks  of  high  importance.  Once  this  has 
been  decided,  any  treatment  strategies  (including  the  specification  of  additional  security  controls 
needed  to  mitigate  the  risk)  should  be  represented  in  the  statement  of  the  security  objectives. 


7. 1.2.4  Security  Requirements  (Chapter  6) 

The  security  requirements  define  both  the  functional  and  assurance  security  requirements  that  the 
STOE  and  the  supporting  evidence  for  its  evaluation  need  to  satisfy  in  order  to  meet  the  security 
objectives.  Once  specified,  the  security  requirements  then  determine  the  selection  of  security 
controls  required  to  ensure  the  protection  of  the  STOE  assets. 

The  SPP-ICS  has  included  security  functional  requirements  and  security  assurance  requirements 
that  extend  ISO  15408  to  cover  issues  associated  with  systems.  These  extensions  are  based  on 
current  ISO  subcommittee  work  to  extend  ISO  15408  to  cover  the  accreditation  of  systems  and 
the  evaluation  of  system  protection  profiles  and  system  security  targets.  These  extensions 
broaden  consideration  of  security  controls  to  include  non-technical  controls  based  on  procedural 
and  management  functions. 
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7. 1.2. 5 Security  Controls 

The  selection  of  appropriate  security  controls  is  driven  by  the  specification  of  the  STOE  security 
requirements.  Security  controls  arc  the  management,  operational,  and  technical  safeguards  and 
countermeasures  prescribed  for  an  information  system  which,  taken  together,  adequately  protect  the 
confidentiality,  integrity,  and  availability  of  the  system  and  its  information.  Please  note  that  the 
selection  of  security  controls  is  not  performed  during  an  SPP.  Rather,  the  selection  of  controls  is 
left  to  the  discretion  of  the  SST  author  (refer  to  section  7.4.1 . 1 for  guidance). 


As  discussed  above,  the  SPP-ICS  has  been  developed  to  capture  the  “generic”  security  needs  of 
the  process  control  industry.  In  doing  so,  it  is  expected  that  the  SPP-ICS  will  be  updated  as  it  is 
applied  in  practice.  This  may  include  further  instantiations  of  the  SPP-ICS  to  address  the  needs 
of  specific  ICS  types,  such  as  those  related  to  SCADA  systems. 

7.2  SPP  Application:  Risk  Management 

Risk  management  is  recognized  as  an  integral  part  of  good  management  practice.  It  is  an 
iterative  process  consisting  of  steps,  which,  when  undertaken  in  sequence,  enable  continual 
improvement  in  decision  making  to  meet  the  business  needs  of  an  organization. 

Generally,  information  security  risk  management  methods  and  techniques  are  applied  to  complete 
information  systems  and  facilities,  but  they  can  also  be  directed  to  individual  system  components 
or  services  where  this  is  practicable,  realistic  and  helpful. 

The  risk  management  process  involves  establishing  the  context,  identifying,  analyzing, 
evaluating,  treating,  communicating  and  monitoring  of  risks.  Each  of  these  stages  of  the  process 
should  be  performed  in  parallel  to  the  SPP  or  SST  development. 

Importantly,  the  risk  management  process  should  be  applied  at  all  stages  in  the  life  cycle  of  a 
product  or  system.  The  following  section  has  been  included  to  equip  the  SPP  reader  with  a brief 
understanding  of  the  risk  management  process.  The  terminology  defined  in  the  next  section  is 
used  throughout  the  remainder  of  the  application  notes. 


Several  forms  of  the  risk  management  process  for  IT  systems  have  been  adopted  by  industry  (e.g. 
NIST  Special  Publication  800-30).  Many  of  these  processes  follow  a common  approach  in 
addressing  information  security  risk  in  systems.  A summary  of  the  approach  includes  the 
following  steps  (as  illustrated  by  Figure  5): 

7. 2. 1.1  Context  Establishment 

Establishes  the  strategic,  organizational  and  risk  management  context  in  which  the  rest  of  the 
process  will  take  place.  Includes  characterizing  the  system  with  respect  to  its  boundaries, 
functions,  data  criticality  and  data  sensitivity. 
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7.2. 1.2  Risk  Identification 
Identify  what,  where  and  how  things  can  arise  as  the  basis  for  further  analysis. 

7. 2. 1.3  Risk  Assessment 

Assessment  of  risks  enables  an  organization  to  determine  which  risks  can  be  accepted  and  which 
risks  require  controls  to  reduce  them.  ISO  17799  and  NIST  Special  Publication  800-53  establish 
a code  of  practice  for  selecting  information  security  controls. 

7. 2 L 3. 1 Risk  A natysis 

Determine  the  existing  controls  and  analyze  risks  in  terms  of  impact  and  likelihood  in  the  context 
of  these  controls.  The  analysis  should  consider  the  range  of  potential  impact  and  how  likely  those 
impacts  are  to  occur.  Impact  and  likelihood  are  typically  combined  to  produce  an  estimated  level 
of  risk. 

Analysis  of  risks  depends  on  the  following  factors: 

> The  nature  of  the  business  information  and  systems 

> The  business  purpose  for  which  the  information  is  going  to  be  used 

> The  environment  in  which  the  system  is  used  and  operated 

> The  protection  provided  by  the  controls  in  place. 

7.2 A 3,2  Risk  Evaluation 

Compare  estimated  levels  of  risk  against  pre-established  criteria.  This  enables  risks  to  be  ranked 
so  as  to  identify  management  priorities.  If  the  levels  of  risk  established  are  low,  then  risks  may 
fall  into  an  acceptable  category  and  treatment  may  not  be  required. 

7.2. 1.4  Risk  Treatment 

Accept  and  monitor  low-priority  risks.  For  other  risks,  develop  and  implement  a specific  risk 
management  plan  with  the  ultimate  goal  of  reducing  the  level  of  risk  down  to  an  acceptable  level 
(through  the  application  of  one  or  more  technical,  management  or  operational  controls).  The 
resultant  risk  (after  security  controls  have  been  applied)  is  referred  to  as  the  residual  risk. 

Options  for  risk  treatment  (which  are  not  necessarily  mutually  exclusive  or  appropriate  in  all 
circumstances),  include  the  following: 

> Risk  Avoidance:  risks  can  be  avoided  by  deciding  not  to  process  with  the  activity  likely  to 
generate  the  risk  (where  this  is  practicable) 

> Reduction  of  Likelihood:  the  likelihood  of  occurrence  of  risk  events  may  be  reduced  by 
reducing  threats  or  vulnerabilities  through  the  application  of  security  controls 

> Reduction  of  Impact:  the  impacts  of  risk  events  may  be  reduced  by  reducing  threats  or 
vulnerabilities  through  the  application  of  security  controls  or  modification  of  the  assets  at 
risk  in  some  other  way 

> Risk  Transference:  transfer  the  risk  (in  whole  or  part)  to  other  parties  (e.g.  insurance 
agencies) 

> Risk  Retention:  after  unacceptable  risks  have  been  reduced  or  transferred,  residual  risks 
may  be  retained 
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7.2. 1.5  Monitor  and  review 

Monitor  and  review  the  performance  of  the  risk  management  system  and  changes  that  might 
affect  it.  Monitor  residual  risks  in  accordance  with  a risk  management  plan. 

7. 2. 1.6  Communicate  and  consult 

Communicate  and  consult  with  internal  and  external  stakeholders  as  appropriate  at  each  stage  of 
the  risk  management  process  and  concerning  the  process  as  a whole. 

The  following  figure  illustrates  the  logical  flow  of  the  risk  management  process: 
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Figure  5 - Overview  of  the  Risk  Management  Process 

Please  note  that  the  risk  management  process  outlined  above  should  not  replace  an  organization’s 
own  risk  management  methodology.  This  model  has  only  been  included  to  illustrate  the 
relationship  of  the  main  elements  of  the  risk  management  process  to  the  SPP-ICS. 

7.3  SPP  Application:  SPP 

This  section  provides  guidance  on  how  to  refine  the  SPP-ICS  into  further  SPP’s  for  specific  ICS 
systems  (e.g.  SCADA  systems). 
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7.3.1  Refinement  of  the  Security  Environment 

7.3.1. 1 Assumptions,  Threats  and  OOSPs 

Due  to  the  high-level  nature  of  the  SPP-ICS,  it  was  difficult  to  specify  detailed  assumptions 
for  a generic  ICS  implementation,  as  the  operational  environment  is  relatively  diverse 
amongst  the  different  process  industry  sectors.  Using  the  included  assumptions  as  a guide, 
the  SPP  author  should  make  a concerted  effort  to  ensure  that  the  assumptions  about  the 
security  aspects  of  the  environment  and/or  the  manner  in  which  the  STOE  is  intended  to  be 
used  are  clearly  defined. 

Conversely,  the  statement  of  threats  in  the  SPP-ICS  covers  a broad  range  of  threats  against 
the  confidentiality,  integrity  and  availability  of  the  STOE.  It  is  noted  that  not  all  of  these 
threats  may  be  applicable  to  the  STOE.  The  SPP  author  should  first  seek  to  confirm  whether 
all  of  the  threat  components  (i.e.  threat  agent,  the  attack  and  asset)  are  applicable  to  their 
operational  environment.  Organizations  with  a well-developed  risk  management  process  will 
have  a better  indication  of  whether  or  not  these  variables  are  applicable  to  their  ICS’ 
operational  environment.  Therefore,  it  is  recommended  that  the  validation  of  threats  be 
performed  against  the  results  of  previous  risk  assessments,  security  audits  etc  that  have 
previously  identified  and  assessed  the  types  of  threats  relevant  to  the  ICS. 

The  overarching  organizational  security  policies  (OOSPs)  common  to  most  organizations 
within  the  process  industry  have  been  included  in  the  SPP.  The  SPP  author  should  ensure 
that  these  cover  both  the  security  policies  of  the  organization  with  responsibility  of  operating 
the  ICS,  as  well  as  those  for  any  external  organizations  interfacing  with  the  ICS. 

7.3. 1.2  System  Assets 

The  system  assets  protected  by  the  STOE  include: 

■ Physical  and  logical  components  of  the  ICS  itself  (e.g.  actuator,  controller,  HMI,  etc) 

■ Remote  diagnostics  and  maintenance  services  and  supporting  mechanisms 

■ Communications  Infrastructure  services  and  technology 

■ The  process  subject  to  control  by  the  ICS 

■ Process  control  information 

■ Process  control  business  or  financial  information 

These  asset  groupings  address  the  most  critical  parts  of  any  ICS.  However,  they  are  generic  in 
nature  and  should  be  refined  in  accordance  with  the  ICS  type.  For  example,  a SCADA 
implementation  may  warrant  the  explicit  definition  of  the  Central  Monitoring  System  (CMS)  and 
the  components  housed  within  the  control  room. 

Example  asset  categories  that  should  be  considered  when  developing  a specific  SPP  include: 

> Information  assets:  databases  and  data  files,  voice  records,  image  files,  system 
documentation,  user  manuals,  training  material,  operational  or  support  procedures, 
continuity  plans,  fallback  arrangements; 
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> Paper  documents:  contracts,  guidelines,  company  documentation,  documents  containing 
important  business  or  financial  data; 

> Software  assets:  application  software,  system  software,  development  tools  and  utilities; 


> Physical  assets:  computer  and  communications  equipment,  magnetic  media  (tapes  and 
disks),  other  technical  equipment  (power  supplies,  air  conditioning  units),  furniture, 
accommodation; 

> Marketing  assets:  company  image  and  reputation;  and 

> Sendees:  computing  and  communications  services,  other  technical  services  (heating, 
lighting,  power,  air-conditioning). 


7.3. 1.3  Vulnerability  and  Threat  Analysis 

A vulnerability  and/or  threat  analysis  is  typically  performed  during  the  risk  analysis  stage  of  a 
risk  assessment.  The  SPP  author  should  use  the  results  of  any  vulnerability  or  threat  analyses 
applicable  to  the  ICS  to  confirm  the  list  of  vulnerabilities  and  threats  in  the  SPP-ICS,  and  refine 
the  definitions  as  appropriate.  Threats  and  vulnerabilities  not  applicable  to  the  STOE  operating 
environment  may  be  removed  from  the  SPP.  Please  note  that  a relationship  exists  between  a 
vulnerability  and  a threat.  The  SPP  author  should  exercise  caution  when  removing  a threat  to 
ensure  that  it’s  corresponding  vulnerability  is  still  exploitable  by  another  threat. 


7.3.2  Risk  Identification 

7.3.2. 1 Identification  of  Risks  to  the  System 

The  SPP-ICS  has  only  focused  on  the  categories  of  risks  applicable  to  a generic  ICS.  The  SPP 
author  should  use  each  category  as  a guide  when  performing  risk  identification.  The  following 
categories  of  risk  have  been  included: 

■ Management  of  the  security  infrastructure  (RISK.MANAGE) 

■ Development  and  implementation  of  Security  Policies  (RISK.SECPOLICY) 

■ Management  of  the  risk  assessment  process  (RISK.RISKMAN) 

■ Compliance  with  internal,  legal  and  statutory  requirements  (RISK.COMPLY) 

■ Asset  classification  and  control  (RISK.ASSETCTRL) 

■ Personnel  security  (RISK. PERSONNEL) 

■ Physical  security  (RISK. PHYSICAL) 

■ Impact  of  natural  disasters  (RISK. ENVIRON) 

■ Illegal  access  to  ICS  components  (RISK.EVIL_ACCESS) 

■ Confidentiality  of  information  (RISK.NEED2KNOW) 

■ Integration  of  security  requirements  (RISK. INTEGRATE) 

■ Protection  of  network  communications  (RISK.NETCOMMS) 

■ Connection  of  IT  systems  (RISK. CONNECT) 
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■ Use  of  Internet  and  email  services  (RISK. INTERNET) 

■ Remote  access  to  the  ICS  network  (RISK. REMOTE) 

■ Delivery  of  online  services  in  support  of  ICS  operation  (RISK. ONLINE) 

■ Operational  management  (RISK.OPSMANAGE) 

■ Monitoring  and  detection  of  security  breeches  (RISK. IDS) 

■ Continuity  of  ICS  operations  (RISK. CONTINUITY) 

Obviously,  not  all  of  the  categories  will  apply  to  all  ICS  types.  For  example,  RISK. REMOTE 
will  not  apply  to  those  organizations  that  do  not  allow  users  to  connect  remotely  to  the  ICS.  The 
technique  used  by  the  SPP  author  to  identify  the  risks  (and  other  risk-related  activities)  should  be 
in  accordance  with  the  organization’s  risk  management  policy. 

Once  the  risk  identification  is  complete,  the  SPP  author  may  then  complete  the  risk  analysis  by 
determining  the  level  of  risk  (following  the  risk  assessment  process  adopted  by  the  organization). 
Once  the  risks  have  been  evaluated  and  prioritized  the  SPP  author  should  obtain  management 
endorsement  so  that  treatment  strategies  for  the  critical  and  other  important  risks  can  be 
developed  and  captured  in  the  SPP.  After  the  risks  and  their  treatment  strategies  have  been 
endorsed,  the  SPP  author  has  a set  of  risks  capable  of  guiding  the  selection  of  the  security 
objectives  (see  next  section).  The  treatment  strategies  may  also  be  used  to  guide  the  selection  of 
security  controls  in  an  SST  (refer  to  section  7.4.1). 

1322  Prior  Risk  Assessment 

Ideally,  a risk  assessment  should  be  performed  prior  to  SPP  development.  However,  tight 
schedules  and  economic  constraints  may  prevent  this  from  happening  in  practice.  Therefore,  one 
cannot  always  assume  that  a risk  assessment  has  been  conducted,  nor  assume  that  the  allocation 
of  security  controls  (which  are  selected  to  meet  the  security  requirements)  for  the  system  has 
been  prioritized  in  accordance  with  the  organization’s  security  and/or  risk  management  policies. 

Assuming  that  a risk  assessment  has  been  conducted,  the  results  of  the  risk  assessment  can  be 
used  to  help  refine  the  various  sections  of  the  SPP-ICS,  including: 

> The  system  context  of  the  risk  assessment  can  be  used  to  help  refine  the  STOE 
description,  including  the  boundaries  and  security  features  implemented  by  the  system 
(defined  in  chapter  2 of  the  SPP-ICS) 

> The  results  of  the  risk  analysis,  such  as  threat  and  vulnerability  assessments,  can  be  used 
to  ensure  that  all  the  relevant  threats  to  the  assets  have  been  captured  in  the  STOE 
operational  environment  (defined  in  chapter  3 of  the  SPP-ICS) 

> The  security  requirements  for  confidentiality,  integrity  and  system  availability  defined  by 
the  risk  assessment  can  be  used  to  extract  a set  of  requirements  to  be  met  by  the  system 
that  are  consistent  with  the  business  needs  of  the  organization  (defined  in  chapter  6 of  the 
SPP-ICS) 

> The  security  objectives  of  the  system  can  be  refined  by  focusing  on  the  greatest  areas  of 
risk,  or  those  residual  risks  that  need  to  be  monitored  in  accordance  with  the 
organizational  risk  management  plan  (defined  in  chapter  5 of  the  SPP-ICS) 
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As  can  be  seen  from  the  above  points,  there  are  significant  advantages  in  having  a risk 
assessment  conducted  prior  to  SPP  development.  Therefore,  the  SPP  author  should  ensure  that 
the  results  of  previous  risk  assessments  are  used  as  input  during  the  development  of  the  SPP. 

7.3.3  Refinement  of  the  Security  Objectives 

The  security  objectives  in  the  SPP-ICS  have  been  selected  based  on  the  needs  of  the  process 
control  industry.  However,  as  mentioned  in  section  7.3.2. 1,  the  set  of  security  objectives  should 
be  driven  by  the  organizational  [prioritized]  need  to  mitigate  identified  risk.  Ideally,  the  SPP 
author  can  reference  previous  risk  assessments  to  determine  the  risks  considered  critical  to  the 
secure  operation  of  the  STOE  and  the  protection  of  its  assets.  These  risks  should  be  used  to 
determine  the  selection  of  the  security  objectives. 

The  SPP  author  may  refine,  modify  or  remove  any  security  objective  that  does  complement  the 
security  functionality  supported  by  the  ICS,  provided  that  all  of  the  risks  corresponding  to  that 
objective  have  been  satisfied  by  another  security  objective.  Further,  the  SPP  author  should  not 
feel  obligated  to  keep  those  security  objectives  that  do  not  contribute  to  the  mitigation  of  the 
identified  risks. 

In  the  scenario  that  an  identified  risk  to  the  organization  is  not  mitigated  by  an  STOE  security 
objective,  the  SPP  author  may  defer  the  treatment  of  that  risk  to  the  STOE  external  operating 
environment.  The  external  operating  environment  is  defined  as  everything  outside  the  scope  and 
boundary  of  the  STOE,  as  defined  by  the  STOE  Description.  Specification  of  security  objectives 
on  the  external  operating  environment  will  differ  for  each  ICS  implementation  given  the  diverse 
nature  of  the  process  control  industry. 


jnt¥  Requirements 


A significant  number  of  security  assurance  and  functional  requirements  have  been  included  in  the 
SPP-ICS.  This  is  due  to  the  complicated  nature  of  system  security  specification.  However,  not 
all  requirements  will  be  relevant  to  every  ICS  implementation.  Therefore,  the  SPP  author  should 
use  discretion  when  selecting  the  requirements  for  their  STOE,  and  be  guided  by  the  security 
objectives  (which  are,  in  turn,  guided  by  the  identified  risks  to  the  system).  Specifying  too  many 
security  requirements  may  result  in  a costly  and  time-consuming  process  should  the  STOE 
undergo  formal  evaluation  or  security  audit  against  the  SPP  security  requirements. 


The  SPP  author  should  also  ensure  that  all  operations  on  the  security  functional  requirements 
have  been  completed. 


7.3.5. 1 Security  Risks  Rationale 

The  security  risks  rationale  is  an  extension  to  the  standard  PP  specification.  It  is  included  in  the 
SPP-ICS  to  demonstrate  that  the  identified  risks  of  the  STOE  are  relevant  to  the  security  problem. 
This  is  achieved  by  extracting  the  identified  threats,  vulnerabilities  and  assets  from  the  security 
environment  and  mapping  them  to  one  or  more  risk  categories.  If  at  least  one  asset,  threat  and 
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vulnerability  combination  can  map  to  one  or  more  risk  categories  then  the  security  risks  are  an 
accurate  and  complete  representation  of  the  security  problem. 

As  mentioned  in  section  7.3.2. 1,  the  SPP  author  should  use  the  risk  categories  as  guidance  to 
complement  the  risk  identification  phase  of  the  ICS  risk  assessment.  Once  the  risk  identification 
is  complete,  the  SPP  author  should  ensure  that  every  risk  is  a product  of  the  threat,  vulnerability 
and  asset  combination.  This  may  also  require  modification  to  the  security  environment  to  ensure 
consistency  between  the  SPP  sections. 

Please  note  that  arguments  for  the  sufficiency  of  the  security  risks  addressing  the  identified 
threats,  vulnerabilities  and  assets  should  also  be  completed  in  the  security  risks  rationale. 

7.3. 5.2  Security  Objectives  Rationale 

The  security  objectives  rationale  has  also  been  extended  to  cover  the  integration  of  risk. 
Specifically,  the  security  objectives  rationale  must  demonstrate  that  the  security  objectives  are 
sufficient  to  meet  the  identified  risks  to  the  STOE.  This  is  achieved  by  showing  that  at  least  one 
risk  maps  to  one  or  more  security  objectives. 

Please  note  that  arguments  for  the  sufficiency  of  the  security  objectives  mitigating  the  identified 
risks  to  the  STOE  should  also  be  completed  in  the  security  objectives  rationale. 


7.4  SP P Application:  SST 

This  section  provides  guidance  on  how  to  claim  conformance  to  the  SPP-ICS  for  specific  ICS 
systems.  Please  note  that  the  guidance  for  “SPP  Application:  SPP”  in  section  7.3  is  also  relevant 
to  an  SST.  Therefore,  this  section  has  only  focused  on  those  areas  of  an  SST  not  already 
addressed  by  the  previous  section. 


7.4.1.1  Selection  of  Controls 

Security  controls  are  included  in  the  SST  to  satisfy  the  security  functional  and  assurance 
requirements.  It  is  beyond  the  scope  of  this  document  to  provide  guidance  on  the  selection  of 
security  controls.  However,  it  is  strongly  recommended  that  the  SPP  author  refer  to  ‘pre-defined' 
libraries  or  catalogues  of  security  controls  to  ensure  that  an  adequate  selection  of  technical, 
management  and  operational  controls  are  included  in  the  SST.  Recommended  security  control 
catalogues  include  ISO  17799  and  NIST  Special  Publication  800-53. 

It  is  worth  noting  that  the  term  ‘security  control’  is  equivalent  to  the  term  ‘security  function'  used 
by  the  CC.  However,  whereas  the  focus  on  the  CC  is  to  specify  IT-based  security  functions  (aka 
TOE  security  functions),  the  application  of  the  CC  to  systems  has  also  introduced  the  notion  of 
non-IT  security  functions  to  ensure  the  correct  management  and  operation  of  the  STOE:  For  the 
sake  of  consistency  with  other  industry  standards  (e.g.  NIST  Special  Publications  800-53  and 
800-30),  security  functions  should  be  referred  to  as  security  controls  in  an  SST.  In  addition, 
security  controls  should  be  categorized  as  either  technical,  management  or  operational  in  nature. 
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7. 4. 1.2  Selection  of  Assurance  Measures 

The  assurance  measures  are  included  in  the  SST  to  satisfy  the  security  assurance  requirements. 
SST  authors  should  note  that  the  assurance  requirements  (and  the  functional  requirements) 
included  in  the  SPP-ICS  are  an  extension  to  the  CC  to  address  the  security  needs  of  systems. 
Therefore,  the  selection  of  assurance  measures  is  likely  to  be  derived  (in  part)  from  management 
and  operational  security  controls. 


7.4.2. 1 Conformance  to  the  SPP-ICS 

SST  authors  should  note  that  conformance  to  the  SPP-ICS  requires  a significant  amount  of 
refinement  to  the  existing  SPP-ICS  content.  This  is  because  in  an  SPP  not  all  aspects  of  the 
operational  environment  are  known,  and  as  a consequence  a risk  analysis  cannot  be  completed 
(only  the  categories  of  risk  have  been  identified  in  the  SPP-ICS).  Therefore,  it  is  recommended 
that  SST  authors  refine  the  SPP  content  prior  to  developing  the  SST  content.  Guidance  on  how  to 
refine  the  SPP  has  been  included  throughout  this  chapter. 

7 A3  Supporting  Rationale 

Application  guidance  on  the  completion  and/or  refinement  of  the  rationale  has  been  included  in 
section  7.3.5.  However,  since  security  controls  are  only  relevant  to  an  SST,  additional  guidance 
is  provided  below. 

7.4.3. 1 STOE  Summary  Specification  Rationale 

In  a product  evaluation,  the  ST  author  must  demonstrate  that  the  IT  security  functions  contribute 
to  the  satisfaction  of  one  or  more  security  functional  requirements.  While  the  approach  is 
identical  for  an  STOE,  the  following  points  should  be  noted: 

■ IT  security  functions  are  referred  to  as  security  controls  in  an  STOE. 

■ Security  controls  are  classified  as  either  technical,  management  or  operational  in  nature. 
All  three  types  of  security  controls  are  usually  required  to  satisfy  a security  requirement, 
although  this  is  left  to  the  discretion  of  the  SST  author. 
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8 Rationale 

8.1  Security  Risks  Rationale 

The  purpose  of  this  rationale  is  to  demonstrate  that  the  identified  security  risks  are  suitable,  that  is  they 
are  sufficient  to  address  the  security  needs,  and  that  they  are  necessary,  ie,  there  are  no 
redundant  security  risks. 

8.1.1  All  Assets,  Threats  and  Vulnerabilities  Addressed 

The  need  to  demonstrate  that  there  are  no  redundant  security  risks  is  satisfied  as  follows: 

• The  first  section  (Table  1 4)  shows  that  all  of  the  assets,  threats  to  security,  and  vulnerabilities 
have  been  addressed. 

• The  second  section  (Table  15)  shows  that  each  security  risk  addresses  at  least  one  assumption, 
policy,  and  threat  combination. 

Table  14  - Mapping  of  Assets,  Threats  and  Vulnerabilities  to  Security  Risks 


Asset/Threat/Vulnerability  Label 

Associated  Security  Risk 

A. ACTUATOR 

R.MANAGE 

R.SECPOLICY 

R.ASSETCTRL 

R. PERSONNEL 

R. PHYSICAL 

R. ENVIRON 

R.EVIL  ACCESS 

R. INTEGRATE 

R. REMOTE 

R.OPSMANAGE 

R. CONTINUITY 

T.BAD  COMMAND 

R.MANAGE 

R.SECPOLICY 

R.RISKMAN 

R. PERSONNEL 

R.EVILACCESS 

R.OPSMANAGE 

R.IDS 

V. PLAINTEXT 

R.MANAGE 

R.SECPOLICY 
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Asset/Threat/Vulnerability  Label 

Associated  Security  Risk 

R.RISKMAN 

R.ASSETCTRL 

R. PERSONNEL 

R.EVILACCESS 

R.NEED2KNOW 

R.NETCOMMS 

R. CONNECT 

R. INTERNET 

R.REMOTE 

R.ONLINE 

R.OPSMANAGE 

R. CONTINUITY 

A. SENSOR 

R.MANAGE 

R.SECPOLICY 

R.ASSETCTRL 

R.RISKMAN 

R. COMPLY 

R.ASSETCTRL 

R. PERSONNEL 

R. PHYSICAL 

R. ENVIRON 

R.EVILACCESS 

R. INTEGRATE 

R.NETCOMMS 

R. CONNECT 

R.REMOTE 

R. INTERNET 

R.OPSMANAGE 

R.IDS 

R.ONLINE 

R. CONTINUITY 

T. REPUDIATE 

R.MANAGE 
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Asset/Threat/V ulnerability  Label  Associated  Security  Ris 


R.SECPOLICY 

R.ASSETCTRL 

R.IDS 


■ 


V. SERVICES 


R.MANAGE 

R.SECPOLICY 

R.RISKMAN 

R.ASSETCTRL 

R. PERSONNEL 

R.EVIL  ACCESS 

R.NEED2KNOW 

R. INTEGRATE 

R.NETCOMMS 

R.CONNECT 

R.INTERNET 

R. REMOTE 

R. ONLINE 

R.OPSMANAGE 

R.IDS 

R. CONTINUITY 


A. CONTROLLER 


R.MANAGE 
R.SECPOLICY 
R.ASSETCTRL 
R.RISKMAN 
R. COMPLY 
R.ASSETCTRL 
R. PERSONNEL 
R. PHYSICAL 
R. ENVIRON 
R.EVIL  ACCESS 
R. INTEGRATE 
R.NETCOMMS 
R.CONNECT 
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Asset/Threat/Vulnerability  Label 

Associated  Security  Risk 

R.REMOTE 

R. INTERNET 

R.OPSMANAGE 

R.IDS 

R.ONLINE 

R. CONTINUITY 

T. PRIVILEGE 

R. MANAGE 

R.SECPOLICY 

R.ASSETCTRL 

R.PERSONNEL 

R. CONNECT 

R. INTERNET 

R.REMOTE 

V. REMOTE 

R. MANAGE 

R.SECPOLICY 

R.RISKMAN 

R.ASSETCTRL 

R.PERSONNEL 

R.EVIL  ACCESS 

R.NEED2KNOW 

R. INTEGRATE 

R.NETCOMMS 

R. CONNECT 

R. INTERNET 

R.REMOTE 

R.ONLINE 

R.OPSMANAGE 

R. CONTINUITY 

A.HMI 

R. MANAGE 

R.SECPOLICY 

R.ASSETCTRL 

R.RISKMAN 

NIST 
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Asset/ThreatA;ulnerabilit\  Label  Associated  Security  Risk 


R. COMPLY 

R.PERSONNEL 

R. PHYSICAL 

R. ENVIRON 

R.EVIL  ACCESS 

R. INTEGRATE 

R.NETCOMMS 

R.CONNECT 

R. REMOTE 

R. INTERNET 

R.OPSMANAGE 

R.IDS 

R.ONLINE 

R. CONTINUITY 

T.NOFAULTRECORD 

R.MANAGE 

R.SECPOLICY 

R.RISKMAN 

R.PERSONNEL 

R.EVILACCESS 

R.NETCOMMS 

R.CONNECT 

R.ONLINE 

R.OPSMANAGE 

R.IDS 

V.  ARCHITECTURE 

R.MANAGE 

R.SECPOLICY 

R.RISKMAN 

R. COMPLY 

R.ASSETCTRL 

R.PERSONNEL 

R. PHYSICAL 

R. ENVIRON 
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Asset/Threat/Vulnerability  Label 

Associated  Security  Risk 

R.EVIL  ACCESS 

R.NEED2KNOW 

R. INTEGRATE 

R.NETCOMMS 

R.CONNECT 

R. REMOTE 

R.INTERNET 

R.OPSMANAGE 

R. ONLINE 

R. CONTINUITY 

A. REMOTE 

R.MANAGE 

R.SECPOLICY 

R.RISKMAN 

R. COMPLY 

R.ASSETCTRL 

R.PERSONNEL 

R. PHYSICAL 

R. ENVIRON 

R.EVILACCESS 

R. INTEGRATE 

R.NETCOMMS 

R.CONNECT 

R. REMOTE 

R.INTERNET 

R.OPSMANAGE 

R. ONLINE 

R. CONTINUITY 

T. INFECTION 

R.SECPOLICY 

R.RISKMAN 

R.ASSETCTRL 

R.PERSONNEL 

R.NETCOMMS 
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Asset/Threat/V  ulnerability  Label 

Associated  Security  Risk 

R. CONNECT 

R.INTERNET 

R.REMOTE 

R. ONLINE 

R.OPSMANAGE 

R. CONTINUITY 

V. NOPOLICIES 

R. MANAGE 

R.SECPOLICY 

R.RISKMAN 

R. COMPLY 

R.ASSETCTRL 

R. PERSONNEL 

R. PHYSICAL 

R. ENVIRON 

R.EVILACCESS 

R. INTEGRATE 

R.NETCOMMS 

R. CONNECT 

R.REMOTE 

R.INTERNET 

R.OPSMANAGE 

R. ONLINE 

R. CONTINUITY 

A.COMMS 

R.MANAGE 

R.SECPOLICY 

R.RISKMAN 

R. COMPLY 

R.ASSETCTRL 

R. PERSONNEL 

R. PHYSICAL 

R. ENVIRON 

R.EVILACCESS 
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Asset/Threat/Vulnerability  Label 

■ ■ ■ ■ . " ■ 

Associated  Security  Risk 

R. INTEGRATE 

R.NETCOMMS 

R.CONNECT 

R. REMOTE 

R. INTERNET 

R.OPSMANAGE 

R.ONLINE 

R. CONTINUITY 

T. DISCLOSURE 

R.RISKMAN 

R.EVILACCESS 

R.NEED2KNOW 

R.NETCOMMS 

R.CONNECT 

R.INTERNET 

R.REMOTE 

R.ONLINE 

R.OPSMANAGE 

V.NOTRAINING 

R.MANAGE 

R.SECPOLICY 

R.RISKMAN 

R.COMPLY 

R.ASSETCTRL 

R. PERSONNEL 

R. PHYSICAL 

R. ENVIRON 

R.EVILACCESS 

R. INTEGRATE 

R.NETCOMMS 

R.CONNECT 

R.REMOTE 

R.INTERNET 

R.OPSMANAGE 
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0 

Asset/Threat/Vulnerability  Label 

Associated  Security  Risk 

R.EVIL  ACCESS 

R.NEED2KNOW 

R. INTEGRATE 

R.NETCOMMS 

R. CONNECT 

R. REMOTE 

R.INTERNET 

R.OPSMANAGE 

R.ONLINE 

R. CONTINUITY 

A.CTRLINFO 

R.SECPOLICY 

R.RISKMAN 

R. COMPLY 

R.ASSETCTRL 

R. PERSONNEL 

R. ENVIRON 

R.EVIL  ACCESS 

R.NEED2KNOW 

R.INTEGRATE 

R.NETCOMMS 

R. CONNECT 

R.INTERNET 

R. REMOTE 

R.ONLINE 

R.OPSMANAGE 

R. CONTINUITY 

T. PHYSIC  ALACCESS 

R. PERSONNEL 

R. PHYSICAL 

R.NETCOMMS 

R.OPSMANAGE 

R. CONTINUITY 

V. NORISK 

R. MANAGE 
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As  set/Th  reat/Vulner  ability  Label 

Associated  Security  Risk 

R.SECPOLICY 

R.RISKMAN 

R. COMPLY 

R.ASSETCTRL 

R. ONLINE 

R.OPSMANAGE 

R.IDS 

R. CONTINUITY 

R. PERSONNEL 

R. PHYSICAL 

R.ENVIRON 

R.EVILACCESS 

R.NEED2KNOW 

R. INTEGRATE 

R.NETCOMMS 

C. CONNECT 

R. INTERNET 

R.REMOTE 

A.BUSINFO 

R.SECPOLICY 

R.RISKMAN 

R. COMPLY 

R.ASSETCTRL 

R. PERSONNEL 

R.ENVIRON 

R.EVILACCESS 

R.NEED2KNOW 

R. INTEGRATE 

R.NETCOMMS 

R.CONNECT 

R.REMOTE 

R. INTERNET 

R.OPSMANAGE 

R. ONLINE 
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Asset/Threat/Vulnerability  Label 

Associated  Security  Risk 

R. CONTINUITY 

T. DISASTER 

R.RISKMAN 

R. PERSONNEL 

R. ENVIRON 

V.SPOF 

R.RISKMAN 

R. PERSONNEL 

R. ENVIRON 

R.EVIL  ACCESS 

R. INTEGRATE 

R.NETCOMMS 

R. CONNECT 

R. INTERNET 

R. REMOTER. ONLINE 

R.OPSMANAGE 

R. CONTINUITY 

T.EVILMOD 

R.RISKMAN 

R.EVILACCESS 

R. CONNECT 

R. INTERNET 

R. REMOTE 

R.OPSMANAGE 

T.EVIL  DESTRUCTION 

R.RISKMAN 

R.EVIL  ACCESS 

R. CONNECT 

R. INTERNET 

R. REMOTE 

R.OPSMANAGE 

R. CONTINUITY 

T.CTRLTAMPER 

R.RISKMAN 

R.EVILACCESS 

R.NETCOMMS 
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Asset/Threat/V ulnerability  Label  Associated  Security  Risk 


R.CONNECT 

R. INTERNET 

R. REMOTE 

R.OPSMANAGE 

R. CONTINUITY 

T. SPOOF 

R.RISKMAN 

R. PERSONNEL 

R. EVIL  ACCESS 

R.NEED2KNOW 

R.NETCOMMS 

R.CONNECT 

R.INTERNET 

R. REMOTE 

R.OPSMANAGE 

T.DOS 

R.RISKMAN 

R.EVILACCESS 

R.NETCOMMS 

R.CONNECT 

R.INTERNET 

R. REMOTE 

R. ONLINE 

R.OPSMANAGE 

R. CONTINUITY 
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Table  1 5 shows  that  there  are  no  unnecessary  IT  security  risks. 


Table  15  - Mapping  of  Security  Risks  to  Assets,  Threats  and  Vulnerabilities 


Risk  Category 
Label 


R1SK.MANAGE 


-A 


Vulnerabilities 

w ''lAlUlt  i't; 


T.BAD  COMMAND, 

T.REPUDIATE, 

T.PRIVILEGE, 

T.NO  FAULT  RECORD, 


V.  PLAINTEXT, 

V. SERVICES, 
V.REMOTE, 

V.  ARCHITECTURE 
V.NOPOLICIES, 

V. NOTRAINING, 

V.3RDPARTY 

V.NORISK 


ASSET.  ACTUATOR. 

ASSET.SENSOR. 

ASSET.CONTROLLER, 

ASSET.HMI, 

ASSET.REMOTE, 

ASSET. COMMS, 

ASSET. CTRLPROCESS 


RISK.SECPOL1CY 


T.BADCOMMAND, 

T.REPUDIATE, 

T.PRIVILEGE, 

T.NO  FAULT  RECORD, 
T.INFECTION 


V.PLAINTEXT, 

V. SERVICES, 
V.REMOTE, 

V.  ARCHITECTURE 
V.NOPOLICIES, 

V. NOTRAINING, 

V.3RDPARTY 

V.NORISK 


ASSET. 

ASSET. 

ASSET. 

ASSET. 

ASSET. 

ASSET-. 

ASSET. 

ASSET. 

ASSET. 


ACTUATOR. 

SENSOR, 

CONTROLLER, 

HMI, 

REMOTE, 

COMMS, 

CTRLPROCESS, 

CTRLINFO, 

BUSINFO 


RISK.RISKMAN 


T. DISCLOSURE, 

T.EVIL_  ANALYSIS, 
T.EVILMODIFICATION, 
T.EVIL  DESTRUCTION, 
T.CTRL  TAMPER, 

T.BAD  COMMAND, 
T.SPOOF,  T.REPUDIATE, 
T.DOS,  T.PRIVILEGE, 
T.NO  FAULT  RECORD, 
T.DISASTER, 
T.INFECTION, 

T. PHYSICAL  ACCESS 


V.PLAINTEXT, 

V. SERVICES, 
V.REMOTE, 

V.  ARCHITECTURE 
, V.SPOF, 
V.NOPOLICIES, 

V. NOTRAINING. 

V.3RDPARTY 

V.NORISK 


ASSET. 

ASSET. 

ASSET. 

ASSET. 

ASSET 

ASSET. 

ASSET. 

ASSET. 

ASSET. 


ACTUATOR, 

SENSOR. 

CONTROLLER, 

HMI, 

REMOTE, 

COMMS, 

CTRLPROCESS, 

CTRLINFO, 

BUSINFO 


RISK.COM  PLY 


TBD 


V.  ARCHITECTURE 
V.NOPOLICIES, 

V. NOTRAINING, 

V.3RDPARTY 

V.NORISK 


ASSET 

ASSET 

ASSET 

ASSET 

ASSET 

ASSET. 

ASSET 

ASSET. 

ASSET 


ACTUATOR, 

SENSOR, 

CONTROLLER, 

HMI, 

REMOTE, 

COMMS, 

CTRLPROCESS, 

CTRLINFO, 

BUSINFO 
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Risk  Category 
Label 

Threats 

Vulnerabilities 

. 

' 

Assets 

■ 

RISK.ASSETCTRL 

T.REPUDIATE, 

T.PRIVILEGE, 

T.INFECTION, 

T.PHYSICAL  ACCESS 

V.  PLAINTEXT, 

V. SERVICES, 
V.REMOTE, 

V.  ARCHITECTURE 

V.NOPOLICIES, 

V.NOTRAINING, 

V.3RDPARTY 

V.NORISK 

ASSET.  ACTUATOR, 

ASSET.SENSOR, 

ASSET.CONTROLLER. 

ASSET.HMI, 

ASSET.REMOTE, 

ASSET.COMMS, 

ASSET. CTRLPROCESS, 

ASSET.CTRLINFO. 

ASSET.BUSINFO 

RISK.PERSONNEL 

T.BAD  COMMAND, 

T. SPOOF,  T.REPUDIATE, 
T.PRIVILEGE, 

T.NO  FAULT  RECORD, 

T. DISASTER. 

T.INFECTION, 

T.PHYSICAL  ACCESS 

V.PLAINTEXT, 

V. SERVICES, 
V.REMOTE, 

V.  ARCHITECTURE 

, V.SPOF, 

V.NOPOLICIES, 

V.NOTRAINING, 

V.3RDPARTY 

V.NORISK 

ASSET.  ACTUATOR, 

ASSET.SENSOR, 

ASSET.CONTROLLER, 

ASSET.HMI, 

ASSET.REMOTE, 

ASSET.COMMS, 

ASSET. CTRLPROCESS,  . 

ASSET.CTRLINFO, 

ASSET.BUSINFO 

RISK.PHYSICAL 

T.PHYSICAL  ACCESS 

V.  ARCHITECTURE 
V.NOPOLICIES, 
V.NOTRAINING, 
V.NORISK 

ASSET.  ACTUATOR. 

ASSET.SENSOR, 

ASSET.CONTROLLER, 

ASSET.HMI, 

ASSET.REMOTE, 

ASSET.COMMS 

RJSK.ENVIRON 

T.DISASTER 

V.  ARCHITECTURE 

V.SPOF, 

V.NOPOLICIES, 

V.NOTRAINING, 

V.NORISK 

ASSET.  ACTUATOR, 

ASSET.SENSOR. 

ASSET.CONTROLLER, 

ASSET.HMI, 

ASSET.REMOTE, 

ASSET.COMMS, 

ASSET.CTRLPROCESS, 

ASSET.CTRLINFO, 

ASSET.BUSINFO 

RISK.EVIL  ACCESS 

T. DISCLOSURE, 

T.EVIL  ANALYSIS, 

T.EVIL  MODIFICATION, 
T.EVIL  DESTRUCTION, 
T.CTRL  TAMPER, 

T.BAD  COMMAND, 

T. SPOOF,  T.REPUDIATE, 
T.DOS,  T.PRIVILEGE, 

T.NO  FAULT  RECORD 

V.PLAINTEXT, 

V. SERVICES, 
V.REMOTE, 

V . A RCH I TECTURE 

, V.SPOF, 

V.NOPOLICIES, 

V.NOTRAINING, 

V.3RDPARTY 

V.NORISK 

ASSET.  ACTUATOR. 

ASSET.SENSOR, 

ASSET.CONTROLLER. 

ASSET.HMI, 

ASSET.REMOTE, 

ASSET.COMMS, 

ASSET.CTRLPROCESS, 

ASSET.CTRLINFO, 

ASSET.BUSINFO 
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Risk  Category 
Label 

:J1 

Threats 

: 

Vulnerabilities 

A ■ ' V"; 

Assets 

■ 

. ■ . , : ' .. 

RISK.NEED2KNOW 

T. DISCLOSURE, 

T.EVIL  ANALYSIS, 

T. SPOOF,  T.PRIVILEGE 

V.PLAINTEXT, 

V.  SERVICES, 
V.REMOTE, 

V.  ARCHITECTURE 

V.NOPOLICIES, 

V.NOTRAINING, 

V.3RDPARTY 

V.NORISK 

ASSET.REMOTE. 

ASSET.COMMS, 

ASSET.CTRLPROCESS, 

ASSET.CTRLINFO, 

ASSET. BUSINFO 

RISK.INTEGRATE 

TBD 

V. SERVICES, 
V.REMOTE, 

V.  ARCHITECTURE 

, V.SPOF, 

V.NOPOLICIES, 

V.NOTRAINING, 

V.3RDPARTY 

V.NORISK 

ASSET.  ACTUATOR, 

ASSET.SENSOR, 

ASSET.CONTROLLER, 

ASSET.HMI, 

ASSET.REMOTE, 

ASSET.COMMS, 

ASSET.CTRLPROCESS, 

ASSET.CTRLINFO, 

ASSET.BUSINFO 

RISK.NETCOMMS 

T. DISCLOSURE, 

T.EVIL  ANALYSIS, 

T.CTRL  TAMPER, 

T. SPOOF,  T.DOS, 

T.NO  FAULT  RECORD, 

T.INFECTION, 

T.PHYSICALACCESS 

V.PLAINTEXT, 

V.  SERVICES, 
V.REMOTE, 

V.  ARCHITECTURE 

, V.SPOF, 

V.NOPOLICIES, 

V.NOTRAINING, 

V.3RDPARTY 

V.NORISK 

ASSET.  ACTUATOR, 

ASSET.SENSOR, 

ASSET.CONTROLLER, 

ASSET.HMI, 

ASSET.REMOTE, 

ASSET.COMMS, 

ASSET.CTRLPROCESS, 

ASSET.CTRLINFO, 

ASSET.BUSINFO 

RISK.CONNECT 

T.DISCLOSURE, 

T.EVIL  ANALYSIS, 

T.EVIL  MODIFICATION, 
T.EVIL  DESTRUCTION, 
T.CTRL  TAMPER. 

T. SPOOF,  T.DOS, 
T.PRIVILEGE, 

T.NO  FAULT  RECORD, 
T.INFECTION 

V.PLAINTEXT, 

V.  SERVICES, 
V.REMOTE, 

V.  ARCHITECTURE 

, V.SPOF, 

V.NOPOLICIES, 

V.NOTRAINING, 

V.3RDPARTY 

V.NORISK 

ASSET.  ACTUATOR. 

ASSET.SENSOR, 

ASSET.CONTROLLER, 

ASSET.HMI, 

ASSET.REMOTE, 

ASSET.COMMS, 

ASSET.CTRLPROCESS, 

ASSET.CTRLINFO, 

ASSET.BUSINFO 

RISK.1NTERNET 

T.DISCLOSURE, 

T.EVIL  ANALYSIS, 

T.EVIL  MODIFICATION, 
T.EVIL  DESTRUCTION, 
T.CTRL  TAMPER, 

T.SPOOF,  T.DOS, 
T.PRIVILEGE, 

T.INFECTION 

V.PLAINTEXT, 

V. SERVICES, 
V.REMOTE, 

V.  ARCHITECTURE 

, V.SPOF, 

V.NOPOLICIES, 

V.NOTRAINING, 

V.3RDPARTY 

V.NORISK 

ASSET.  ACTUATOR, 

ASSET.SENSOR, 

ASSET.CONTROLLER, 

ASSET.HMI, 

ASSET.REMOTE, 

ASSET.COMMS, 

ASSET.CTRLPROCESS, 

ASSET.CTRLINFO, 

ASSET.BUSINFO 
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Risk  Category 
Label 

Vulnerabilities 

RISK.REMOTE 

T. DISCLOSURE, 

T.EVIL  ANALYSIS, 

T.EVIL  MODIFICATION, 
T.EVIL  DESTRUCTION, 
T.CTRL  TAMPER. 

T. SPOOF,  T.DOS, 
T.PRIVILEGE, 

T.INFECTION 

V.PLAINTEXT, 

V. SERVICES, 
V.REMOTE, 

V.  ARCHITECTURE 

, V.SPOF, 

V.NOPOLICIES, 

V.NOTRAINING, 

V.3RDPARTY 

V.NORISK 

ASSET.  ACTUATOR, 

ASSET.SENSOR. 

ASSET.CONTROLLER. 

ASSET.HMI, 

ASSET.REMOTE, 

ASSET. COMMS, 

ASSET. CTRLPROCESS, 
ASSET.CTRLINFO, 

ASSET. BUSINFO 

RISK.ONLINE 

T. DISCLOSURE.  T.DOS, 
T.NO  FAULT  RECORD. 
T.INFECTION 

V.PLAINTEXT, 

V. SERVICES, 
V.REMOTE. 

V.  ARCHITECTURE 

, V.SPOF, 

V.NOPOLICIES. 

V.NOTRAINING, 

V.3RDPARTY 

V.NORISK 

ASSET.  ACTUATOR. 

ASSET.SENSOR, 

ASSET.CONTROLLER. 

ASSET.HMI, 

ASSET.REMOTE. 

ASSET. COMMS, 

ASSET. CTRLPROCESS, 
ASSET.CTRLINFO. 

ASSET. BUSINFO 

RISK.OPSMANAGE 

T. DISCLOSURE. 

T.EVIL  ANALYSIS, 

T.EVIL  MODIFICATION, 
T.EVIL  DESTRUCTION, 
T.CTRL  TAMPER. 

T.BAD  COMMAND. 

T. SPOOF,  T.REPUDIATE, 
T.DOS.  T.PRIVILEGE, 

T.NO  FAULT  RECORD. 
T.DISASTER. 

T.INFECTION, 

T.PHYSICALACCESS 

V.PLAINTEXT, 

V.  SERVICES, 
V.REMOTE, 

V.  ARCHITECTURE 

, V.SPOF, 

V.NOPOLICIES, 

V.NOTRAINING. 

V.3RDPARTY 

V.NORISK 

ASSET.  ACTUATOR. 

ASSET.SENSOR. 

ASSET.CONTROLLER. 

ASSET.HMI, 

ASSET.REMOTE. 

ASSET.COMMS, 

ASSET.CTRLPROCESS, 

ASSET.CTRLINFO, 

ASSET.BUSINFO 

RISK.IDS 

T.BAD  COMMAND. 
T.REPUDIATE, 

T.NO  FAULT  RECORD, 

V. SERVICES, 
V.NOPOLICIES. 
V.NOTRAINING, 
V.NORISK 

ASSET.  ACTUATOR. 

ASSET.SENSOR. 

ASSET.CONTROLLER, 

ASSET.HMI, 

ASSET.REMOTE, 

ASSET.COMMS, 

ASSET.CTRLPROCESS 

RISK.CONTINUITY 

T.EVIL  DESTRUCTION, 
T.CTRL  TAMPER. 

T.BAD  COMMAND, 

T.DOS,  T.DISASTER. 
T.INFECTION, 

T. PHYSICAL  ACCESS 

V.PLAINTEXT, 

V. SERVICES. 
V.REMOTE, 

V.  ARCHITECTURE 

, V.SPOF. 

V.NOPOLICIES, 

V.NOTRAINING, 

V.3RDPARTY 

V.NORISK 

ASSET.  ACTUATOR. 

ASSET.SENSOR. 

ASSET.CONTROLLER. 

ASSET.HMI, 

ASSET.REMOTE, 

ASSET.COMMS, 

ASSET.CTRLPROCESS, 

ASSET.CTRLINFO, 

ASSET.BUSINFO 

L_ 
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8,1  2 Security  Risks  are  Sufficient 

Due  to  the  generic  nature  of  this  SPP  and  the  need  for  additional  refinement  of  the  sources  of 
risks  and  identified  assets,  threats  and  vulnerabilities,  sufficiency  arguments  have  not  been 
included.  SPP/SST  authors  should  note  that  additional  rationale  is  required  in  order  to 
demonstrate  that  the  risks  are  sufficient  to  address  the  security  needs  (refer  to  the  application 
notes  for  guidance). 


8.2  Security  Objectives  Rationale 

Tlie  purpose  of  this  rationale  is  to  demonstrate  that  the  identified  security  objectives  are  suitable,  that 
is  they  are  sufficient  to  address  the  security  needs,  and  that  they  are  necessary,  ie,  there  are  no 
redundant  security  objectives. 


>tion$,  Threats  and  Policies  Adds 


The  need  to  demonstrate  that  there  are  no  redundant  security  objectives  is  satisfied  as  follows: 

• The  first  section  (Table  1 6)  shows  that  all  of  the  secure  usage  assumptions,  threats  to  security, 
and  organizational  security  policies  have  been  addressed. 

• The  second  section  (Table  1 7)  shows  that  each  security  objective  counters  at  least  one 
assumption,  policy,  or  threat. 


Table  16  - Mapping  of  Assumptions,  Threats,  and  OSPs  to  Security  Objectives 


Threat/Policy/Assumption  Label 

Associated  Security  Objective 

A.PHYSICALACCESS 

0. PHYSICAL 

0. INTERCONNECTIVITY 

O. CONTINUITY 

0. REMOTE 

O.ACCESSCONTROL 

0. MONITORING 

O. AUDIT 

O.IDS 

O.RISK 

T. DISCLOSURE 

O.RISK 

O. INTERCONNECTIVITY 

O.DATAAUTHENTICATION 

O. MANAGEMENT 

0.3RDPARTY 

O. REMOTE 

O. COMPLIANCE 
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Threat/Policy/Assumption  Label 

Associated  Security  Objective 

O.ACCESSCONTROL 

O. SECURE  COMMS 

0. DATA  INTEGRITY 

0. CONFIDENTIALITY 

P. EVENT 

O. PHYSICAL 

O.RISK 

0.  INTERCONNECTIVITY 

0. CONTINUITY 

O. MANAGEMENT 

0.3RDPARTY 

O. REMOTE 

O.ACCESS  CONTROL 

O.SECURE  COMMS 

0.  AVAILABILITY 

0. MONITORING 

A.COMMS  ACCESS 

0. PHYSICAL 

O. INTERCONNECTIVITY 

O. CONTINUITY 

O. MANAGEMENT 

0.3RDPARTY 

O. REMOTE 

O.ACCESS  CONTROL 

O.  AVAIL  ABILITY 

T.EVILANALYSIS 

0. PHYSICAL 

O. INTERCONNECTIVITY 

O.DATAINTEGRITY 

0.3RDPARTY 

0. REMOTE 

O. SYSTEM  INTEGRITY 

O. MONITORING 

0. AUDIT 

P. PERSONNEL 

O. PHYSICAL 
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Threat/Policy/ Assumption  Label 

1 

.1 

Associated  Security  Objective 

O. MANAGEMENT 

0.3RDPARTY 

O.ACCESS  CONTROL 

O.DATA  INTEGRITY 

O.  S Y STEMINTEGRITY 

O. MONITORING 

O.IDS 

O. AUDIT 

A.EXTERNAL 

O. INTERCONNECTIVITY 

O. CONTINUITY 

O. MIGRATION 

O. COMPLIANCE 

0.3RDPARTY 

O.SECURECOMMS 

O.DATA  INTEGRITY 

O.  AVAILABILITY 

O. MONITORING 

T.EVIL  MODIFICATION 

0. PHYSICAL 

O.SYSTEMINTEGRITY 

0.  MONITORING 

0. REMOTE 

O. SECURE  COMMS 

O.DATAAUTHENTICATION 

DATA  INTEGRITY 

P. INFRASTRUCTURE 

O.RISK 

O.NON  INTERFERENCE 

O.DATABACKUP 

O.ACCESSCONTROL 

O. CONTINUITY 

O. MANAGEMENT 

O. MIGRATION 

O. COMPLIANCE 
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Threat/Policy/Assumption  Label 

Associated  Security  Objective 

O.IDS 

A. REMOTE 

O. PHYSICAL 

O.ACCESS  CONTROL 

O. CONFIDENTIALITY 

O. MANAGEMENT 

0.3RDPARTY 

0. REMOTE 

O.SYSTEMINTEGRITY 

O. MONITORING 

O.IDS 

T.EVILDESTRUCTION 

O.DATAINTEGRITY 

O.ACCESS  CONTROL 

O. MONITORING 

0.3RDPARTY 

0. REMOTE 

0.  AVAIL  ABILTIY 

P. CONFIGURATION 

O. PHYSICAL 

0. INTERCONNECTIVITY 

O.DATAAUTHENTICATION 

O. MANAGEMENT 

0. MIGRATION 

O.SYSTEMINTEGRITY 

T.CTRLTAMPER 

0. PHYSICAL 

O.DATAAUTHENTICATION 

O.ACCESSCONTROL 

O. SECURE  COMMS 

O.DATA  INTEGRITY 

O.SYSTEM  INTEGRITY 

O.SYSTEM  DIAGNOSTICS 

O. MONITORING 

P. PHYSICAL 

0. PHYSICAL 
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Threat/Policy/Assumption  Label 

Associated  Security  Objective 

O. INTERCONNECTIVITY 

O.ACCESS  CONTROL 

O. SECURE  COMMS 

O. REMOTE 

O.SYSTEM  INTEGRITY 

O. MONITORING 

O.IDS 

T.BADCOMMAND 

O.NON  INTERFERENCE 

O.DATA  AUTHENTICATION 

O. SECURE  COMMS 

O.DATAJNTEGRITY 

O. CONFIDENTIALITY 

O.  AVAILABILITY 

O.SYSTEM  INTEGRITY 

O.SYSTEMDIAGNOSTICS 

P. POLICY 

O.RISK 

O.NON  INTERFERENCE 

O.DATABACKUP 

O.DATAAUTHENTICATION 

O.ACCESSCONTROL 

O. CONFIDENTIALITY 

O. CONTINUITY 

O. MANAGEMENT 

O. MIGRATION 

O. COMPLIANCE 

0.3RDPARTY 

O. REMOTE 

O.IDS 

O. AUDIT 

T. SPOOF 

O.DATA  AUTHENTICATION 

O.ACCESS  CONTROL 

O. CONFIDENTIALITY 

System  Protection  Profile  - Industrial  Control  Systems 
Version  1.0 


Page  124  of  151 


National  Institute  of  Standards  & Technology 
System  Protection  Profile  - Industrial  Control  Systems 


NIST 

tiottanoi  Institute  of 
Sttmdprds  pnd  Technology 


Threat/Policy/ Assumption  Label 

Associated  Security  Objective 

O. MANAGEMENT 

0.3RDPARTY 

0. REMOTE 

O.SYSTEMINTEGRITY 

P. ASSETS 

O.RISK 

O.MIGRATIOON 

0. COMPLIANCE 

T. REPUDIATE 

O.DATAAUTHENTICATION 

O.ACCESSCONTROL 

O.DATAINTEGRITY 

O. MANAGEMENT 

P. SAFETY 

O.NON-INTERFERENCE 

0. CONTINUITY 

0. MANAGEMENT 

O. MIGRATION 

0. COMPLIANCE 

0.3RDPARTY 

0. REMOTE 

O.SYSTEMDI  AGNOSTICS 

T.DOS 

O. CONTINUITY 

0.3RDPARTY 

0. REMOTE 

O.ACCESSCONTORL 

O.SECURECOMMS 

0.  AVAIL  ABILITY 

0. AUDIT 

P.NOINTERFERE 

O.NONINTEREERENCE 

0. MANAGEMENT 

0. MIGRATION 

0. COMPLIANCE 

T. PRIVILEGE 

O.DATAAUTHENTICATION 
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Threat/Policy/ Assumption  Label 

Associated  Security  Objective 

O. MIGRATION 

0.3RDPARTY 

O. REMOTE 

O.ACCESSCONTROL 

O.DATAINTEGRITY 

0. CONFIDENTIALITY 

O.SYSTEMINTEGRITY 

O. MONITORING 

O.IDS 

P. BUSINESS 

O.DATA  BACKUP 

O. CONTINUITY 

O. MANAGEMENT 

O. MIGRATION 

O.  AVAILABILITY 

T.NOFAULTRECORD 

O.SYSTEMDI  AGNOSTICS 

O. MONITORING 

O. AUDIT 

O.IDS 

P.RISK 

O.RISK 

O. MANAGEMENT 

O. MIGRATION 

T.DISASTEER 

0. CONTINUITY 

O. MANAGEMENT 

0. MIGRATION 

O.AVAILABILTIY 

P. ENVIRONMENT 

O. PHYSICAL 

O.RISK 

O. NONINTERFERENCE 

O.  MANAGEMENT 

0. CONTINUITY 

O.  MIGRATION 
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Threat/Policy/Assumption  Label  Associated  Security  Objective 


0. SYSTEM  INTEGRITY 

O.AVAILABILTIY 

T. OUTAGE 

O.  AVAILABILITY 

0. CONTINUITY 

O.NON  INTERFERENCE 

O.DATA  BACKUP 

T. INFECTION 

0. INTERCONNECTIVITY 

O.DATA  BACKUP 

O.DATAAUTHENTICATION 

0.3RDPARTY 

O. REMOTE 

O.SECURECOMMS 

O.DATA  INTEGRITY 

0. SYSTEM  INTEGRITY 

O. MONITORING 

T.PHYSICALACCESS 

0. PHYSICAL 

O.RISK 

O. INTERCONNECTIVITY 

0.3RDPARTY 

0. REMOTE 

O.ACCESSCONTROL 

O.SYSTEM  INTEGRITY 

0. MONITORING 

0. AUDIT 

O.IDS 

Table  1 7 shows  that  there  are  no  unnecessary  IT  security  objectives. 


Table  17  - Mapping  of  Security  Objectives  to  Threats,  Policies  and  Assumptions 
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Security  Objective 

■ 

Threats 

Policies 

' ' : ...  : ...  : 

Assumptions 

O.MANAGEMENT 

T.DISCLOSURE, 

T.  SPOOF, 

T.REPUDIATE 

T.DISASTER 

P.EVENT, 

P.PERSONNEL, 

P.  INFRASTRUCTURE 

P. CONFIGURATION, 

P. POLICY 

P.SAFETY 

P.NO  INTERFERE 

P. BUSINESS 

P.RISK 

P.ENVIRONMENT 

A.COMMSACCESS, 

A.REMOTE, 

O.MIGRATION 

T.PRIVILEGE 

T.DISASTER 

P.INFRASTRUCTURE 

P. CONFIGURATION 

P.ASSETS 

P.SAFETY 

P.NO  INTERFERE 

P. BUSINESS 

P.RISK 

P.ENVIRONMENT 

A.EXTERNAL; 

O.COMPLIANCE 

T.DISCLOSURE 

P.INFRASTRUCTURE 

P.POLICYP.  ASSETS 

P.SAFETY 

P.NO  INTERFERE 

A.EXTERNAL 

0.3RDPARTY 

T.DISCLOSURE 

T.EVIL  ANALYSIS 

T.EVILDESTRUCTION 

T.  SPOOF 

T.DOS 

T.PRIVILEGE 

T.INFECTION 

T.PHYSICAL  ACCESS 

P.EVENT 

P.PERSONNEL 

P. POLICY 

P.SAFETY 

A.COM1VIS  ACCESS 

A.EXTERNAL 

A.REMOTE 
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Security  Objective 


O.REMOTE 


Threats 

\ s ' V Nvv  ' s 


Policies 


T. DISCLOSURE 

T.EVIL_  ANALYSIS 

T.EVILMODIFICATION 

T.EVILDESTRUCTION 

T.SPOOF 

T.DOS 

T.PRIVILEGE 
T.INFECTION 
T.PHYSICAL  ACCESS 


P.EVENT 
P.  PHYSICAL 
P. POLICY 
P.SAFETY 


A.PHYSICAL  ACCESS 

A.COMMSACCESS 

A.REMOTE 


O.ACCESS  CONTROL 


T.EVIL  DESTRUCTION 
T.CTRL  TAMPER 
T.SPOOF 
T.REPUDIATE 
T.DOS 

T.PRIVILEGE 
T.PHYSICAL  ACCESS 


P.EVENT 
P.  PERSONNEL 
P.INFRASTRUCTURE 
P. PHYSICAL 
P.POLICY 


A.PHYSICAL  ACCESS 

A.COMMSACCESS 

A.REMOTE 


O.SECURE  COMMS 


T. DISCLOSURE 
T.EVILMODIFICATION 
T.CTRL  TAMPER 
T.BAD  COMMAND 
T.INFECTION 


P.EVENT 
P. PHYSICAL 


A.EXTERNAL 


O.DATA  INTEGRITY 


T. DISCLOSURE 
T.EVILANALYSIS 
T.EVIL  MODIFICATION 
T.EVILDESTRUCTION 
T.CTRL  TAMPER 
T.BAD  COMMAND 
T.REPUDIATE 
T.PRIVILEGE 
T.INFECTION 


P.  PERSONNEL 


A.EXTERNAL 


O.CONFIDENTIALITY 


T. DISCLOSURE 
T.BADCOMMAND 
T.SPOOF 
T.PRIVILEGE 


P.POLICY 


A.REMOTE 
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Security  Objective 

Threats 

' - . ^ . , ' . '5  \ 

Policies 

Assumptions 

O.AVAILABILITY 

T.BADCOMMAND 

P.EVENT 

A.COMMSACCESS 

T.DOS 

T.DISASTER 

T.OUTAGE 

P. BUSINESS 

P.ENVIRONMENT 

A.EXTERNAL 

O.SYSTEM  INTEGRITY 

T.EVELANALYSIS 

T.EVIL  MODIFICATION 

T.CTRL  TAMPER 

T.BADCOMMAND 

T. SPOOF 

T.PRIVILEGE 

T.INFECTION 

T.PHYSICALACCESS 

P.PERSONNEL 

P. CONFIGURATION 

P. PHYSICAL 

P.ENVIRONMENT 

A.REMOTE 

O.SYSTEMDIAGNOSTICS 

T.CTRLTAMPER 

T.BAD  COMMAND 

T.NO  FAULT  RECORD 

P.SAFETY 

O.MONITORING 

T.EVIL  ANALYSIS 

P.EVENT 

A.PHYSICAL  ACCESS 

T.EVILMODIFICATION 

T.EVIL  DESTRUCTION 

T.CTRL-TAMPER 

T.PRIVILEGE 

T.NO  FAULT  RECORD 

T.INFECTION 

T.PHYSICAL  ACCESS 

P.PERSONNEL 

A.EXTERNAL 

A.REMOTE 

P.PHYSICAL 

O.AUDIT 

T.EVIL  ANALYSIS 

T.DOS 

T.NO  FAULT  RECORD 

T.PHYSICAL  ACCESS 

T.OUTAGE 

P.PERSONNEL 

P. POLICY 

A.PHYSICAL  ACCESS 

CUDS 

T.PHYSICALACCESS 

P. POLICY 

A.REMOTE 

T.NO  FAULT  RECORD 

T.PRIVILEGE 

P. PHYSICAL 

P.INF  RESTRUCTURE 

A.PHYSICAL  ACCESS 

T.DOS 

P.PERSONNEL 
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8»2,2  Security  Qlbiecttves  sre  Sufficient 

Due  to  the  generic  nature  of  this  SPP  and  the  need  for  additional  refinement  of  the  identified 
security  objectives,  assumptions,  threats  and  organizational  security  policies,  sufficiency 
arguments  have  not  been  included.  SPP/SST  authors  should  note  that  additional  rationale  is 
required  in  order  to  demonstrate  that  the  security  objectives  are  sufficient  to  address  the  security 
needs  (refer  to  the  application  notes  for  guidance). 


uectives 


u tiler  identified  msm 


The  purpose  of  this  section  is  to  show  that  the  security  objectives  are  suitable  to  address  the  identified 
security  risks.  Table  1 8 and  Table  1 9 show  that  each  security  objective  is  necessary,  that  is,  each 
security  risk  is  addressed  by  at  least  one  security  objective  and  vice  versa. 


Table  18  - Mapping  of  Security  Risks  to  Security  Objectives 


Security  Risk 

Security  Objectives 

R.MANAGE 

O.DATA  AUTHENTICATION 

0. MANAGEMENT 

0.3RDPARTY 

O. AUDIT 

R.SECPOLICY 

O.DATAAUTHENTICATION 

0. REMOTE 

0.  AVAILABILITY 

O.DATABACKUP 

0.3RDPARTY 

O.RISK 

O.MANAGEMENT 

0. COMPLIANCE 

R.RISKMAN 

O.RISK 

0 . DAT  AINTEGRIT  Y 

O.ACCESS  CONTROL 

R. COMPLY 

O. COMPLIANCE 

R.ASSETCTRL 

O.MANAGEMENT 

0. MIGRATION 

R. PERSONNEL 

O.MANAGEMENT 

O.RISK 
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Security  Objectives 


O.ACCESSCONTROL 

0. MIGRATION 

R. PHYSICAL 

O. PHYSICAL 

R.ENVIRON 

0. CONTINUITY 

0.  AVAILABILITY 

R.EVILACCESS 

O.DATA  INTEGRITY 

0. SECURE  COMMS 

O.ACCESSCONTROL 

O.SYSTEMINTEGRITY 

R.NEED2KNOW 

0. CONFIDENTIALITY 

O.ACCESSCONTROL 

R. INTEGRATE 

0.3RDPARTY 

O.MIGRATION 

O.NON  INTERFERENCE 

R.NETCOMMS 

O.SECURE  COMMS 

O.ACCESSCONTROL 

O.DATAAUTHENTICATION 

R.CONNECT 

O. INTERCONNECTIVITY 

0. COMPLIANCE 

0. DATA  AUTHENTICATION 

0.  REMOTE 

R. INTERNET 

O. COMPLIANCE 

0. MONITORING 

R.REMOTE 

0.3RDPARTY 

0. REMOTE 

O.DATAINTEGRITY 

0. MONITORING 

O.DATAAUTHENTICATION 

R.ONLINE 

O.DATAAUTHENTICATION 

0. INTERCONNECTIVITY 
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Security  Risk 

Security  Objectives 

0. MONITORING 

0. AUDIT 

0. REMOTE 

R.OPSMANAGE 

0 . S Y STEMINTEGRIT  Y 

O.SYSTEM  DIAGNOSTICS 

0. MONITORING 

O.NONINTERFERENCE 

O.DATAAUTHENTICATION 

O.RISK 

0. MANAGEMENT 

O. MIGRATION 

O.CONFIDENTIALITY 

R.IDS 

O.IDS 

O.MONITORING 

0. AUDIT 

R. CONTINUITY 

O.CONTINUITY 

O. INTERCONNECTIVITY 

O.AVAILABILITY 

O.DATABACKUP 

Table  19  - Mapping  of  Security  Objectives  to  Security  Risks 


Security  Objective 

Security  Risks 

0. PHYSICAL 

R. PHYSICAL 

O.RISK 

R.SECPOLICY 

R.RISKMAN 

R.PERSONNEL 

R.OPSMANAGE 

O.NONINTERFERENCE 

R. INTEGRATE 

R.OPSMANAGE 

O.INTERCONNECTIVITY 

R.CONNECT 
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R.ONLINE 

R. CONTINUITY 

O.DATABACKUP 

R.SECPOLICY 

R. CONTINUITY 

O.DATA  AUTHENTICATION 

R.MANAGE 

R.SECPOLICY 

R.NETCOMMS 

R.CONNECT 

R. REMOTE 

R.ONLINE 

R.OPSMANAGE 

0. CONTINUITY 

R.ENVIRON 

R. CONTINUITY 

O.MANAGEMENT 

R.MANAGE 

R.SECPOLICY 

R.ASSETCTRL 

R.PERSONNEL 

R.OPSMANAGE 

0. MIGRATION 

R.ASSETCTRL 

R.INTEGRATE 

R.OPSMANAGE 

0. COMPLIANCE 

R.SECPOLICY 

R. COMPLY 

R.CONNECT 

R. INTERNET 

0.3RDPARTY 

R.MANAGE 

R.SECPOLICY 

R.INTEGRATE 

R. REMOTE 

0. REMOTE 

R.SECPOLICY 
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R. CONNECT 

R.REMOTE 

R.ONLINE 

O.ACCESSCONTROL 

R.RISKMAN 

R. PERSONNEL 

R.EVIL  ACCESS 

R.NEED2KNOW 

R.NETCOMMS 

O.SECURECOMMS 

R.EVILACCESS 

R.NETCOMMS 

O.DATA  INTEGRITY 

R.RISKMAN 

R.EVILACCESS 

R.REMOTE 

0. CONFIDENTIALITY 

R.NEED2KNOW 

R.OPSMANAGE 

O.  AVAILABILITY 

R.SECPOLICY 

R.ENVIRON 

R. CONTINUITY 

O.SYSTEM  INTEGRITY 

R.OPSMANAGE 

R.EVILACCESS 

R.OPSMANAGE 

O.SYSTEM  DIAGNOSTICS 

R.OPSMANAGE 

O. MONITORING 

R.INTERNET 

R.REMOTE 

R.ONLINE 

R.OPSMANAGE 

R.IDS 

O. AUDIT 

R.MANAGE 

R.ONLINE 

R.IDS 
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Due  to  the  generic  nature  of  this  SPP  and  the  need  for  additional  refinement  of  the  sources  of  risk 
and  the  identified  security  objectives,  sufficiency  arguments  have  not  been  included.  SPP/SST 
authors  should  note  that  additional  rationale  is  required  in  order  to  demonstrate  that  the  security 
objectives  are  sufficient  to  counter  the  identified  security  risks  (refer  to  the  application  notes  for 
guidance). 


8.3  Security  Requirements  Rationale 


The  purpose  of  this  section  is  to  show  that  the  identified  security  requirements  are  suitable  to 
meet  the  security  objectives.  Table  20  and  Table  21  show  that  each  security  requirement  is 
necessary,  that  is,  each  security  objective  is  addressed  by  at  least  one  security  requirement  and  vice 
versa.  Note  that  some  objectives  are  partially  satisfied  by  the  STOE  and  partially  satisfied  by  the  IT 
environment.  Security  Objectives  for  the  STOE  are  satisfied  by  security  functional  and  assurance 
requirements.  Security  Objectives  for  the  Environment  are  satisfied  by  IT  requirements  for  the 
environment. 


Table  20  - Mapping  of  Security  Objectives  to  Security  Requirements 


Security  Objectives 

Security  Requirements 

O .BoundaryProtection 

FPT  PHP.l,  FPT  PHP.2,  FPT  PHP.3 

FPT  PHP.4.  PHY  SOB.l 

O.Risk 

AVAVLA.2 

AMAAMP.l 

AMAEVD.l 

0 .Noninterference 

FTPJTC.l  FTP  TRP.l,  FPT  SEP 

AVA_MSU.2 

.1 

O.Data_Backup 

FDP  UIT.2,  FPT  RCV.2,  FPT  RCV.3, 

FPT  RCV.4,  FPT  FLS.l.FPT  AMT.l, 
FPTTST.l 

O.Data_Authentication 

FIA  UAU.3,  FIA  UAU.4,  FIA  UAU.7, 

FIA  UID.l,  FDP  DAU.2,  FMT  MTD.l, 

FMT  SMR.  1 , FPT  RPL.  1 
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Security  Objectives 


0. Continuity 


Security  Requirements 


P.BusinessContinuity 
FRUFLT.l,  FPTFLS.l,  FPTRCV.5 
FMT  SMF.l 


0. Verify 


ATEFUN.l,  ATE  IND.2,  ATE  AST.  1 
ADO  IGS.l,  FPT  AMT.l,  FPT  TST.l 


O. Ownership 


FMTSMR.  1 , FMTSMR.2,  FMTMOF.  1 . 
FMTMOF.2,  FMT  REV.l,  FMT  SMF.l, 
P. Personnel,  P. Infrastructure 


O. Migration 


P.AssuranceMaintenance 
P.  Personnel 


O. Compliance 


P.PolicyProcdures 


O. Collaborate 


P.PolicyProcedures 


O. Access  Control 


FDP  ACC.  1,  FDP  ACF.l,  FDP  IFC.l, 
FDP  IFF.  1 , FI  A UAU.  1 , FIAUAU.2, 
FIAUID.2,  FMTREV.l,  FMT  MOF.2, 
FIA  AFL.  1 , FTP  TRP.  1 , FTA  TSE.  1 , 
FIA  SOS.l,  FIA  SOS.2,  FMT  SAE.  1 , 
FPT  STM.  1,  FPT  SEP 


O.CommsIntegrity 


FPT  ITA.  1 , FPT  ITC.  1 , FPT  ITI.  1 , 

FPT  ITI.2,  FPT  RCV.5,  FPT  RPL.l, 
FPT  SSP.  1 , FPT  SSP.2,  FPT  STM.  1 , 
FPT  TDC.l,  FTP  ITC.  1,  FTP  TRP.l 
FpT  tst.1,  FDP  ETC.l,  FDP  ETC.2, 
FDP  ITC.  1 , FDP  ITC.2,  FDP  UCT.  1 , 
FDP  UIT.l,  FDP  UIT.2,  FDP  IFF.  1, 

FCS  COP.l,  FCS  CKM.4,  FMT  MOF.l, 
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Security  Objectives 

Security  Requirements 

O. Available 

FPT  FLS.l,  FPT  TRC.l,  FPT  ITA.l, 
FRUFLT.l,  FRUPRS.l,  FRU  PRS.2 

O . C ontroll  ntegrity 

FMT  MSA.  1,  FPT  TST.l,  FPT  AMT.l, 
FPTFLS.l 

O. Event  Monitor 

FAU  ARP.  1 , FAUSAA.  1 , FAUS  AA.2 

FAU  SAA.3,  FAU  SAA.4,  FAU  SEL.l 

FPT  IT1.1,  FPT  IT1.2 

FEM  EDI.l,  FEM  EDI. 2,  FEM  EDI.3, 

FEM  EDI.4,  FAU.GEN.l,  FAU  GEN.2 

FPT  TDC.  1 , FMT  SMF.  1 , FMT  SMR.  1 

O.EventLog 

FAU  GEN.l,  FAU  GEN.2,  FAU  SEL.l 

FAU  SAR.l,  FAU  SAR.2,  FAU  SAR.3, 

FAU  STG.  1,  FAU  STG.2,  FAU  STG.3, 

FAU  STG.4,  FPT  STM 

O.IDS 

FAU  ARP.  1 FAU  SAA.UFAU  SAA.2, 

FAU  SAA.3,  FAU  SAA.4,  FPT  ITI.l, 

FPT  ITI.2,  FEM  EDI.l,  FEM  ED1.2 

_ : ij 

Table  21  - Mapping  of  Security  Requirements  to  Security  Objectives 


Requirements 

Objective 

■ 

FAUARP.l 

O. Event  Monitor 

FAUGEN.l 

0. Event  Monitor 

FAUGEN.2 

O. Event  Monitor 

FAUSAA.l 

O. Event  Monitor 

FAUSAA.2 

O.EventMonitor 

FAUSAA.3 

0. Event  Monitor 

FAUSAA.4 

0. Event  Monitor 

FAUSEL.l 

0. Event  Monitor 

FCSCKM.4 

O.CommsIntegrity 
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Requirements 

Objective 

FCSCOP.l 

O.CommsIntegrity 

FDP  ACC.  1 

O.AccessControl 

FDPACF.l 

0. Event  Monitor 

FSPDAU.2 

O.DataAuthentication 

FDP  ETC.  1 

O.Comms  Integrity 

FDPETC.2 

O.Comms  Integrity 

FDPIFF.l 

O . C ommslntegr  ity 

O.AccessControl 

FDPITC.2 

O.CommsIntegrity 

FDPUCT.l 

O.CommsIntegrity 

FDPUIT.l 

O.CommsIntegrity 

FDPUIT.2 

O.CommsIntegrity 

O.DataBackup 

FEMEDFl 

0 . E ventMon  itor 

FEMEDI.2 

O.EventMonitor 

FEMEDF3 

0. Event  Monitor 

FEMEDI.4 

0. Event  Monitor 

FIAAFL.l 

O.AccessControl 

FIASOS.l 

0. Access  Control 

FIASOS.2 

O.AccessControl 

FIAUAU.l 

O.AccessControl 

FIAUAU.2 

O.Access_Control 

FIA_UAU.3 

O.DataAuthentication 

FIAUAU.4 

0.  DataAuthentication 

FIAUAU.7 

O.DataAuthentication 

NIST 

Matkmol  ot 

Standards  and  tacttaotogy 
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^ ■ 

Objective 

FIAUID.l 

O.Data  Authentication 

FIAUID.2 

O.Access_Control 

FMT  MOF.l 

O.CommsIntegrity 

O. Ownership 

FMTMOF.2 

O.AccessControl 

O. Ownership 

FMTMSA.l 

O. Control  Integrity 

FMTMTD.l 

O.Data  Authentication 

FMTREV.l 

O. Ownership 

FMTREV.2 

O.AccessControl 

FMTSAE.l 

O.Access_Control 

FMTSMF.l 

O.EventMonitor 

0.  Ownership 

O.  Continuity 

FMTSMR.l 

O.EventMonitor 

0. Ownership 

O.Data  Authentication 

FMTSMR.2 

O.  Ownership 

FPTAMT.l 

O.ControlIntegrity 

O.  Verify 

O.Data_Backup 

FPTFLS.l 

O. Control  Integrity,  O.Data  Backup 

O. Available 

O. Continuity 

FPTITA.l 

O. Available 

FPTJTC.l 

O.CommsIntegrity 

FPTITL1 

0. Event  Monitor 
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Requirements  Objective 


FPTITI.2 

O.EventMonitor 

FPTPHP.l 

O. Boundary  Protection 

FPT  PHP.2 

0. Boundary  Protection 

FPT  PHP.3 

O. Boundary  Protection 

FPTPHP.4 

O.BoundaiyProtection 

FPT  RCV.2 

O.DataBackup 

FPT  RCV.3 

O.DataBackup 

FPTRCV.4 

O.DataBackup 

FPTRPL.l 

0 . C ommslntegri  ty 

O.DataAuthentication 

FPTSEP.l 

O.Non-Interference 

O.CommsIntcgrity 

FPTSSP.l 

0 . C ommslntcgr  i ty 

FPTSSP.2 

O.CommsIntegrity 

FPTSTM.l 

O.CommsIntcgrity 

O.AccessControl 

FPTTDC.l 

0. Event  Monitor 

FPTTRC.l 

0. Available 

FPTTST.l 

O.ControlIntegrity 

0. Verify 

O.DataBackup 

FRU_FLT.l 

0. Available 

0. Continuity 

FRU_PRS.l 

O. Available 

FRUPRS.2 

0. Available 

FTA  TSE.l 

0. Access  Control 
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Requirements 


Objective 


FTPITC.l 

O.Comms  Integrity 

0. Non-Interference 

FTPTRP.  1 

O.Comms  Integrity 

O.Access_Control 

0. Non-Interference 

- . 


Due  to  the  generic  nature  of  this  SPP  and  the  need  for  additional  refinement  of  the  sources  of  risk 
and  the  identified  security  objectives,  sufficiency  arguments  have  not  been  included.  SPP/SST 
authors  should  note  that  additional  rationale  is  required  in  order  to  demonstrate  that  the  security 
objectives  are  sufficient  to  counter  the  identified  security  risks  (refer  to  the  application  notes  for 
guidance). 


Due  to  the  generic  nature  of  this  SPP  and  the  need  for  additional  refinement  of  the  security 
requirements,  a dependency  analysis  has  not  been  included.  SPP/SST  authors  should  note  that  a 
dependency  analysis  is  required  in  order  to  show  that  the  dependencies  between  the  security 
requirements  have  been  addressed  by  the  SPP/SST  (refer  to  the  application  notes  for  guidance). 


8.4  Rationale  for  Extensions 


tlOi 


m n 


This  section  provides  the  rationale  for  the  inclusion  of  the  explicit  system  assurance  requirements, 
as  noted  in  Table  18.  An  overview  for  each  class  will  address  from  a security  controls 
perspective,  the  contribution  to  system  security  provided  by  the  noted  assurance  component(s). 


8.4. 1.1  Class  ASA:  Security  awareness 


The  need  to  communicate  the  security  responsibilities  expected  of  personnel  can  be  supported 
with  the  development  of  complete  and  consistent  documentation  describing  those  expectations. 
Although,  the  ISO/IEC  15408  Part  3 AGD  class  could  easily  be  interpreted  to  include  the 
procedural  security  functions  as  well  as  the  IT  security  functions,  the  provider  and  focus  of  the 
documentation  is  different.  In  a systems  context,  the  usage  documentation  will  contain  specifics 
about  the  system  that  product  documentation  cannot. 

The  security  policy  and  procedures  documents  class,  PPD,  provides  the  requirements  for 
documentation  describing  security  expectations,  procedures  and  policies  for  personnel  accessing 
the  assets.  The  component(s)  in  this  class  are  used  to  gain  confidence  that  personnel  are  informed 
of  those  procedural  expectations  so  that  the  security  can  be  maintained. 
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8. 4. 1.2  Class  ASC  System  operational  and  management  security  controls 

The  ASC  class  is  closely  derived  from  the  technical  security  control  based  assurance  ASD  class. 
Operational  security  is  concerned  with  the  physical,  policy,  procedural,  personnel,  and  other 
organisational  security  control  measures  that  are  used  in  the  operational  environment  to  protect 
the  STOE;  as  well  as  support  its  business  function.  For  instance  System  support  of  degraded 
operations,  as  part  of  continuing  business  operations  in  response  to  natural  or  man-made  events 
(see  PBC  in  section  4).  Management  security  is  concerned  with  the  provision  of  management  and 
infrastructure  support  enable  the  operational  security  controls  and  technical  security  controls  to 
effectively  be  used.  The  objective  of  this  activity  is  to  assess  the  completeness,  accuracy,  and 
usability  of  the  system  operational  and  management  security  controls  components  of  the  system, 
and  to  verify  that  the  security  and  operational  policies,  procedures,  organization  and  physical 
assets  support  the  system  security  requirements  that  are  allocated  to  them.  This  is  achieved 
through  examination  of  the  policies  and  procedures  and  physical  system  control  security 
attributes,  and  any  associated  design  and  configuration  documentation.  The  latter  becomes 
especially  important  if  there  is  a direct  interface  to  the  IT  part  of  the  system  security.  This  may 
also  include  observation  and  interviews  with  personnel  to  gain  insight  to  the  strength  of  the 
organization  security  infrastructure.  As  noted  above,  the  PPD  class  will  also  contribute  to 
confidence  gained  that  personnel  are  informed  of  the  system  security  related  procedures. 


8. 4. 1.3  Class  ACM:  Configuration  Management 

The  objective  of  Configuration  Management  during  evaluation  is  to  provide  assurance  that  the 
evaluator  has  the  correct  version  of  all  system  components  for  the  other  evaluation  activities.  It 
applies  therefore  to  measures  within  the  development  environment,  not  the  operational 
environment.  When  the  operational  system  is  deployed,  configuration  management  is  a series  of 
system  capabilities  allowing  operational  decision  makers  to  control  the  configuration  and  changes 
to  it.  The  most  recent  evaluation  evolves  to  be  the  baseline,  and  will  be  maintained  as  such  by  the 
organization.  Any  proposed  modifications,  bug  fixes,  or  system  capability 
upgrades/enhancements  will  be  controlled  and  evaluated  against  the  most  recent  evaluated 
baseline,  and  that  baseline  will  be  updated  accordingly.  Additionally,  operational  and 
maintenance  security  controls  will  also  be  updated  as  necessary  to  respond  to  the  changing  threat 
and  operational  environment.  These  too  will  be  evaluated  from  a system  security  impact 
perspective  and  changes  will  be  controlled  accordingly,  as  part  of  the  system  security 
configuration. 

8.4. 1.4  Class  ADO:  Delivery  and  operation 

The  purpose  of  the  system  delivery  and  operation  activity  is  to  judge  the  adequacy  of  the 
documentation  of  the  procedures  used  to  ensure: 

• That  the  system  components  can  be  delivered  to  the  operating  organization  without 
modification; 
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• That  the  system  can  be  accepted  by  the  operating  organization  and  that  it  is  put  under 
configuration  control; 

• That  the  system  components  can  be  installed,  generated  and  started  into  an  initial  secure 
configuration  that  verifies  interoperability  between  components; 

• That  the  system  can  be  configured  to  enforce  the  policies  that  govern  day-to-day 
operations. 

• Site  interoperability  can  be  ensured,  such  that  the  security  relevant  system,  subsystem, 
external  and  component  interfaces  that  comprise  the  System  TOE,  especially  those  to 
legacy  security  controls  can  be  started  up,  and  interoperate  in  a secure  manner  in  the 
intended  operational  environment 

The  ADO  IGS  documentation  shall  be  used  to  assure  that  the  system  transition  incorporating  the 
patch,  upgrade,  or  new  components  into  the  operational  environment  can  be  conducted 
transparently  and  without  disruption  to  system  availability  and  integrity. 


8.4. 1 .5  Class  ASD:  System  Architecture,  Design  and  Configuration  Documentation 

The  ASD  assurance  class  is  closely  derived  from  the  ADV  class  in  1SO/IEC  15408  Part  3. 
However,  the  necessary  development  and  integration  information  appropriate  for  systems  is 
different  enough  from  those  in  the  current  status  that  it  was  determined  that  a separate  class  was 
appropriate  avoid  confusion. 

The  purpose  of  this  class  is  to  assess  the  completeness,  coherency  and  consistency  of  the  system 
architecture,  design  and  operational  configuration  documentation  and  to  verify  that  the  system 
architecture,  design  and  configuration  reflect  the  security  requirements  allocated  to  the  various 
subsystems  and  components  of  the  system.  This  is  achieved  through  examination  of  increasingly 
refined  descriptions  of  the  System  Security  Function  (SSF)  architecture,  design  and  configuration 
documentation. 

This  class  is  closely  related  to  the  ADV  assurance  class  for  product  design  abstractions.  However, 
because  so  many  changes  are  needed  to  meet  the  needs  of  system  level  design,  a complete  new 
class  is  added.  This  may  be  merged  at  a later  time  with  ADV  but  for  now  the  differences  are 
viewed  significant  enough  that  a new  class  is  warranted. 


8.4. 1.6  Class  AGD  Guidance  documents 

The  purpose  of  the  guidance  document  family  is  to  judge  the  adequacy  of  the  documentation 
describing  the  integration  and  operational  use  of  the  system.  Such  documentation  includes  that 
aimed  at  system  integrators,  trusted  administrators  and  non-administrative  users  whose  incorrect 
actions  could  adversely  affect  the  security  behaviour  and  characteristics  of  the  system,  as  well  as 
that  aimed  at  normal  users  whose  incorrect  actions  could  adversely  affect  the  ability  of  the  system 
to  provide  the  required  protection  capabilities  for  their  own  data. 
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Therefore,  the  AGD  activity  is  closely  related  to  the  processes  and  procedures  defined  by  the 
operational  security  requirements.  The  user  and  administrator  guidance  includes  information 
regarding  the  technology  aspects  of  the  system  as  well  as  the  operational  and  human  processes  of 
the  system. 

Thei'e  are  additional  types  of  users  in  a distributed  system,  and  their  roles  and  responsibilities 
extend  beyond  the  traditional  user  and  administrator  categories  required  user  documentation. 

Each  of  the  user  roles  need  to  know  both  the  technical  and  management  and  operational  security 
controls  needed  to  accomplish  their  business  mission. 

One  of  these  users  may  be  external  systems  that  are  considered  outside  the  STOE.  The  critical 
issue  is  that  if  there  is  a component  that  interfaces  with  the  STOE  but  for  whatever  reason  the 
component  is  not  part  of  the  STOE,  then  it  is  necessary  to: 

a)  Define  the  interfaces  between  the  STOE  and  the  external  component; 

b)  Define  the  security  properties,  if  any,  that  are  provided  by  or  that  are  provided  across  the 
interfaces, 

c)  Define  how  the  STOE  and  external  component  will  authenticate  themselves  to  each  other; 

d)  Define  the  secure  method  by  which  the  STOE  and  the  external  component  will 
communicate  such  that  a security  policy  is  enforced; 

e)  Define  the  security  agreement  between  the  parties  with  responsibility  for  operating  the 
STOE  and  the  external  component  to  establish  the  business  rules  that  govern  how  that 
interface  is  to  be  used  and  maintained  over  time. 

f)  Define  the  security  relevant  configuration  parameters  that  allow  implementation, 
integration,  and  enforcement  of  system  security  policies. 

The  guidance  documents  family  applies  to  those  functions  and  interfaces  which  are  related  to  the 
security  of  the  system  as  a whole.  In  principle,  the  notion  of  providing  users  'all  information 
necessary  to  maintain  the  security...’  applies  directly  to  system  evaluations.  However,  in  practice, 
c product  administrator  guide  will  provide  instructions  on  how  to  change  settings;  in  a system 
context  the  values  to  be  set  are  decided  so  the  administrator  guidance  will  instruct  on  exactly  how 
to  configure  the  system  to  optimize  security  in  its  distributed  environment.  In  addition,  it  could 
be  that  the  AGD  components  cover  all  the  evidence  of  security  controls  that  require  that  users  be 
made  aware  of  policies  and  procedures  because  they  provide  the  information  required  for  the  user 
to  securely  operate  within  and  as  part  of  the  system. 

It  is  often  wrongly  assumed  that  there  would  only  be  one  guidance  document  for  the  system 
administrator,  while  in  fact  there  could  be  multiple  pieces  of  guidance  for  different  administrator 
roles.  This  is  particularly  true  in  a distributed  system  context  where  different  portions  of  the 
system  may  be  administered  and  maintained  by  completely  different  roles.  This  may  also  apply 
to  the  operational  user  guidance  - different  types  of  users  may  be  issued  different  guidance 
documents.  In  addition,  the  system  integrator  is  considered  a user  of  the  system  and  requires 
detailed  integration  and  check-out  procedural  guidance  to  ensure  that  any  given 
component/product  is  securely  integrated  into  the  system. 
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8.4. 1.7  Class  ALC  Life  cycle  support 

The  purpose  of  the  life-cycle  support  class  is  to  judge  the  adequacy  of  the  procedures  used  during 
the  integration  and  operational  life-cycle  of  the  system.  These  procedures  include  the  security 
measures  used  throughout  system  development  (i.e.,  integration),  the  life-cycle  model  used  by  the 
integrator,  and  the  tools  used  by  the  integrator  throughout  the  life-cycle  of  the  system. 

The  process  of  life  cycle  support  is  much  more  extensive,  and  increasingly  important  in  a system 
context.  This  is  due  to  the  composition  of  a system  being  a collection  of  various  products  that  are 
integrated  together  to  support  business  operations  and  security  requirements  that  protect  those 
operations.  The  system,  which  may  be  widely  distributed,  requires  procedures  to  monitor  and 
track  the  system  from  its  inception  as  an  operational  entity,  until  it  is  securely  retired  from  the 
organisation.  System  security  controls  need  to  be  evaluated  at  regular  intervals;  and  the  system 
components  tracked  both  from  a parts  obsolescence  perspective,  related  supportability  aspects, 
and  modifications  to  increase  functionality,  replace  obsolete  parts,  take  advantage  of  more 
efficient  technology,  add  a interface  to  another  system,  and  respond  to  a new  or  different  threat 
environment.  In  this  regard,  following  the  STOE’s  initial  verification  and  authorisation  for 
operation,  ALC  becomes  inherently  tightly  coupled  to  AMA.  ALC  aspects  may  be  considered 
more  of  a local  issue,  where  the  system  is  monitored  for  maintenance  and  performance.  An 
example  being  that  a bug  may  be  found,  or  an  obsolete  part  notification  might  be  received  from  a 
vendor,  or  a software  end  of  support  life  notice.  These  issues  would  be  handled  more  informally 
with  the  vendor  or  by  the  system  IT  department.  They  may  also  be  contractual  obligations  that 
drive  the  organisation’s  response,  and  the  vendor’s  requirements.  Whereas  upgrading  the  STOE 
for  a new  capability,  adding  an  interface,  or  response  to  a new  threat,  would  be  more  broad 
brushed,  and  have  a potentially  greater  impact  on  the  System’s  security  contribution,  both  from 
technical  security  and  operational  and  management  security  controls  perspective.  The  Life  Cycle 
Development  plan  and  procedures  and  the  Assurance  Maintenance  Plan  should  complement  and 
support  each  other.  Any  proposed  or  actual  change  would  still  require  an  impact  analysis  to 
ensure  that  the  change  will  not  have  a negative  impact  to  either  system  performance  or 
functionality  for  business  or  security  support. 

As  with  ACM,  once  the  system  has  been  received  and  enters  day-to-day  operations,  the  system 
has  to  be  entered  into  the  organisation’s  configuration  management  and  life  cycle  support 
systems.  The  system  integrator  then  may  play  a prominent  role  in  the  day-to-day  maintenance  of 
the  system  in  support  of  its  operations.  ALC  and  its  product  and  development  focused  activities, 
would  then  literally  transform  to  operations  related  activities  that,  in  turn  would  closely  track  and 
support  AMA  activities. 

As  such,  from  operations  assurance  perspective,  it  is  proposed  that  one  family  be  introduced, 

ALC  OPS,  from  which  the  system  would  transition  to  (from  ALC  DEV),  following  its 
introduction  into  day-to-day  operations.  ALC  FLR  while  germane  for  systems,  the  general 
responsibility  becomes  more  organisation  focused,  with  system  integrator,  or  organisation  IT 
personnel  playing  a larger  role,  and  developer  responsibilities  being  more  contractual  in  nature. 
The  premise  for  systems  is  that  following  the  established  procedure  in  the  operational 
environment  should  provide  greater  confidence  that  evaluation  results  remain  sound.  However, 
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the  flaw  correction  and  related  information  will  still  be  subject  to  the  impact  analysis  and 
evaluation  process  defined  in  AMA,  as  part  of  the  continuous  monitoring  and  change  process. 


8. 4. 1.8  Class  ATE  Test 

The  purpose  of  this  family  is  to  verify  that  the  system  components,  when  installed,  integrated  and 
configured  in  accordance  with  the  system  architecture  and  system  configuration  evidence,  meet 
the  security  functional  requirements  specified  in  the  SST  and  are  effective  in  enforcing  the  system 
security  concept  of  operations.  System  architecture,  integration  and  design  documentation  aid  in 
test  development  and  execution.  This  is  accomplished  by  determining  that  the  SSF  has  been 
configured  as  specified  by  the  configuration  specification,  tested  against  the  relevant  architecture 
and  design  evidence,  by  performing  a sample  of  the  developer's  tests,  and  by  independently 
testing  a subset  of  the  SSF. 

The  term  Test  campaign’  is  used  to  denote  the  entirety  of  the  test  activities  performed. 

A system  presents  the  following  issues  that  are  addressed  by  the  test  campaign: 

a)  Physical  distribution  of  the  system  components; 

b)  Whether  or  not  the  system  components  have  been  evaluated.  In  the  case  where  the 
component  is  evaluated,  the  differences  between  the  evaluated  configuration  and  the 
configuration  of  the  component  when  used  in  the  system  context  raises  issues; 

c)  The  impact  of  the  specific  operational  environment  and  its  contribution  to  assurance; 

d)  Achieving  secure  integration  of  system  components  through  development  of  specialized 
functionality; 

e)  Varying  levels  of  assurance  allocated  to  different  physical  or  logical  components  of  the 
system. 

The  system  evaluation  test  criteria  accommodates  the  need  for  a flexible  test  campaign  that 
provides  for  the  following: 

a)  the  availability  of  evaluated  products  and  evidence  about  the  products, 

b)  the  degree  of  assurance  desired  for  the  various  parts  of  the  system, 

c)  the  existence  of  specialised  functionality  to  integrate  components  into  the  system  and  the 
degree  of  assurance  required  for  that  specialised  functionality. 

d)  the  specific  configuration  decisions  that  enable  the  system  to  implement  the  system 
security  requirements  and  system  security  concept  of  operation. 
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System  testing  must  address  the  operational  and  management  security  controls  of  the  system  in 
addition  to  the  technical  security  control  portion.  The  system  introduces  concerns  for  maintaining 
the  system  configuration  on  a day-to-day  basis  in  response  to  a changing  environment  and  the 
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need  for  repeated  vulnerability  assessments  to  ensure  that  the  system  continues  to  provide 
effective  countermeasures.  This  class  addresses  the  testing  of  the  operational  and  management 
security  controls  aspects  of  system  security,  and  verifies  its  contribution  to  system  security.  The 
test  effort  is  primarily  two-fold;  the  first  tests  that  there  is  a well-documented  mapping  of  the 
policy,  applicable  procedures  personnel  and  physical  attributes  of  the  organisation  to  the  system 
TSF.  Second  that  there  is  a testable,  clear  and  unambiguous  communications  medium  to  status, 
exchange  and  report  security  information  among  the  various  security  controls  of  the  System. 


8.4. 1.9  Class  AYA  Vulnerability  analysis 

The  purpose  of  the  vulnerability  assessment  activity  is  to  determine  the  existence  and 
exploitability  of  flaws  or  weaknesses  in  the  system  as  configured  for,  and  implemented  in  its 
intended  environment.  This  determination  is  based  upon  analysis  performed  by  the  developer  and 
the  evaluator,  with  inputs  from  the  consumer;  and  is  supported  by  evaluator  testing. 

Inherently,  the  AVA  activity  is  closely  related  to  the  system  security  policy  and  procedures, 
physical  security  measures,  personnel  security,  and  having  security  infrastructure  in  place  to 
effectively  counter  any  system  vulnerabilities.  The  system  strength  of  security  function 
encompasses  all  security  controls  aspects  to  ensure  that  the  system  remains  secure  and  any 
breaches  can  be  effectively  countered. 

The  notion  of  vulnerability  assessment  is  greatly  expanded  in  a system  context,  due  to  the  added 
complexity  when  compared  to  a product.  The  added  system  complexity  not  only  can  increase  the 
vulnerability  access  points,  but  it  also  can  increase  potential  ways  to  counter  a vulnerability.  This  is 
because  system  security  measures  can  be  more  robust  because  of  the  systems  approach,  which 
inherently  encompasses  a broader  type  set.  Additionally,  the  system  also  encompasses  operational 
and  management  security  controls  aspects,  such  as  physical  boundary  monitoring,  auditing 
mechanisms,  and  more  extensive  and  better  training  of  personnel  to  create  a broader  corporate 
atmosphere  of  security  awareness.  The  vulnerability  assessment  activity  should  be  conducted 
throughout  the  system  life  cycle  to  ensure  that  the  security  controls  change,  as  needed,  and  remain 
effective  in  the  changing  threat  environment. 


8.4.1.10  Class  AMA  Assurance  maintenance 

The  purpose  of  the  assurance  maintenance  activity  is  to  assure  that  the  system  will  continue  to 
maintain  its  security  assurance  baseline  as  changes  are  made  to  the  system  itself  or  to  its 
environment.  Such  changes  may  include  new  threats  or  vulnerabilities,  changes  to  the  system  or 
environment  that  can  have  a security  impact,  changes  in  personnel,  and  modifications  or  changes 
to  the  system’s  external  interfaces.  This  activity  includes  both  technical  and  operational  and 
management  security  controls  elements. 

The  notion  of  assurance  maintenance  is  pronounced  in  a system  context  because  of  the  typical 
system  complexity  and  incorporation  of  the  mix  of  security  controls  features.  Therefore,  any 
change/modification/upgrade  to  any  of  the  security  components  of  the  system  will  require  an 
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analysis  to  determine  the  impact  to  secure  system  operation  itself;  and  to  determine  if  an 
unrelated  feature  may  have  to  be  modified  to  contribute  to  system  security,  due  to  those  changes. 

The  assurance  maintenance  activity  is  an  ongoing  activity  that  is  applicable  to  any  changes  in  the 
system  environment  that  may  impact  security,  throughout  the  system  life  cycle.  These  changes 
could  range  from  a new  facility  intrusion  detection  system,  to  the  addition  of  a new  emergency 
generator  that  will  be  used  by  the  system,  to  an  additional  external  interface  that  the  system  must 
exchange  data  with.  And  in  fact,  an  additional  external  interface  to  the  system,  would  involve  the 
definition  of  that  interface,  any  new  vulnerabilities  that  could  be  introduced  via  that  interface,  and 
both  technical  and  operational  and  management  security  controls  related  documentation  would 
necessarily  need  to  be  updated,  driven  by  the  system  need  to  accommodate  the  new  interface. 

A change  in  the  operational  environment  itself  will  necessitate  an  evaluation  of  security  aspects 
of  the  system  security  baseline,  and  how  best  to  accommodate  that  change.  That  change  may  be 
all-inclusive  and  impact  the  system  as  a whole,  or  it  may  impact  a single  domain  of  the  system. 

In  the  latter  case,  existing  system  components  may  be  able  to  accommodate  the  security  aspects 
of  the  change,  or  by  just  tweaking  the  configuration  to  accommodate  security  aspects  of  the 
operational  environment.  There  needs  to  be  a change  mechanism  in  place  and  documented  in 

AMA  for  a product  is  typically  a developer  function.  However,  that  role  will  necessarily  shift  to 
the  system  owner  for  a system.  This  is  due  primarily  to  the  interaction  of  technical  and 
operational  security  controls  of  the  system,  especially  when  considering  the  operational  security 
policies  and  procedures  that  will  govern  human  behavior,  which  typically  tends  to  evolve  over 
time.  The  length  and  breadth  of  security  controls  system  components,  which  includes  event 
monitoring,  augments  system  security  but  also  necessarily  increases  the  role  of  the  system  owner 
in  support  of  this  function. 


8.5  Strength  of  Function  Claims 

This  SPP  does  not  include  any  strength  of  functions  claims. 
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Appendix  A - Acronyms 


cc 

EAL 

ICS 

IT 

N1AP 

NIST 

NSA 

PP 

PSF 

SF 

SFP 

SOF 

SP 

SPP 

ST 

SST 

STOE 

TSC 

TSF 

SSF 

TSFI 

TSP 


Common  Criteria 

Evaluation  Assurance  Fevel 

Industrial  Control  System 

Information  Technology 

National  Information  Assurance  Partnership 

National  Institute  of  Standards  and  Technology 

National  Security  Agency 

Protection  Profde 

Procedural,  Policy,  Personnel  & Physical  Security  Functions 

Security  Function 

Security  Function  Policy 

Strength  of  Function 

Special  Publication 

System  Protection  Profile 

Security  Target 

System  Security  Target 

System  Target  of  Evaluation 

TSF  Scope  of  Control 

Technical  Security  Functions 

System  Security  Functions 

TSF  Interface 

TOE  Security  Policy 
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